Oren Eini

CEO of RavenDB

a NoSQL Open Source Document Database

Get in touch with me:

oren@ravendb.net +972 52-548-6969

Posts: 7,567
|
Comments: 51,185
Privacy Policy · Terms
filter by tags archive
time to read 4 min | 708 words

I love NMock, it's a good framework and it allows you to do so many nice things so easily. It's the single library that I know of whose documentation is a single page, and it's both accurate and useful.

One of the nice things in NMock is the ability to define expectations and constraints. So you can say:

mockObj.Expect("MethodName"new And(new IsTypeOf(typeof(IList), new PropertyIs("Count",1));

To check that this is an IList with a single element. Sometimes, however, you need more, and often enough it's a one off thing. For those cases, I build the DelegatingConstraint:

public class DelegatingConstraint : BaseConstraint 
 {
  private readonly CheckValue checkValue;
  private readonly string message;
  public delegate bool CheckValue(object val);
  public delegate string ReturnMessage(object val);
  public DelegatingConstraint(CheckValue checkValue, string message)
  {
   if(checkValue==null)
    throw new ArgumentNullException("checkValue");
   if(message==null)
    throw new ArgumentNullException("message");
   this.checkValue = checkValue;
   this.message = message;
  }
  public override bool Eval(object val)
  {
   return checkValue(val);
  }
  
  public override string Message
  {
   get
   {
    return message;
   }
  }
 }

Here is how you would use it in .Net 1.1:

DelegatingConstraint dl = new DelegatingConstraint(new DelegatingConstraint.CheckValue(MyConstraint),"Failed to validate on my constraint"));
mockObj.Expect("MethodName",dl);
...
public bool MyConstraint(object val)
{
   //Complex bussiness logic to validate that the correct object was sent goes here
}

It's simpler in .Net 2.0, of course, but I'm not working with that yet.

More interesting than validation, though, is the possiblity to modify the value that you get, so you simulate a method modifying the sent object*.

* Beware Of Abuse.

[Listening to: לשם - מירי מסיקה - Heralds, Harpers, & Havoc(04:02)]
time to read 2 min | 338 words

I've blogged before on the difficulities of testing an application's UI, but for the last two days I gave it one more try. It should be simple, but the complexities of the UI are dirving me nuts.

I'm giving up, it's too complex to give anything back to me. I find that I spend far more time just writing test than writing code, and the code that I write doesn't push me all that much forward. How do you test for a situation such as:

When creating new project, close all the current project document, unless there are unsaved documents, then you need to ask the user and potentially save the documents or cancel the new project creation.

On this last rule I spent the last two days, trying to express it in a suit of tests that would mean something, and wouldn't be a big pile of code that would break any time I would touch the UI.

I would love to hear from other people about their experiance in testing UI, but I fear that with the current tools, that is just too hard to do properly. My current solution is to divide each form into two parts, one would be the UI itself, and the other one would be the Context class, which I talked about before. That way I can at least test some parts of what the UI do and I would have some seperation between the UI and the controlling code.

Perhaps I could return to this later on and try, but right now it just take too much (bloody) time to do it.

time to read 3 min | 587 words

I'm currently using mocks to create the Controller, before writing any GUI code whatsoever, which means that I've an interface for View, and I'm using mocks throughout the tests. The library that I'm using is NMock*, which allows to setup Expectations such as expecting calls on a spesific method.

The really nice thing about NMock is that it let you knows if you called a method too many times (just had it in one of my tests, and there was no way that I would have found out about this if I didn't have tests and if I didn't use NMock. However, if you want to know if a method was not called, you need to call the Verify() method. This is a ripe ground for forgetting to do so and creating bad tests, so now I've the following system:

[TestFixture]
public class ControllerTests
{
 private Controller controller;
 private Mock mockMgr;
 [SetUp]
 public void SetUp()
 {
  mockMgr = new DynamicMock(typeof(IViewManager));
  controller = new Controller(TestDataUtil.CreateTestManager(),
   (IViewManager)mockMgr.MockInstance);
 }
 [TearDown]
 public void TearDown()
 {
  mockMgr.Verify();    
 }
 [Test]
 public void DisplayProject()
 {
  mockMgr.ExpectAndReturn("CloseProject",true);
  mockMgr.Expect("DisplayProject",new IsTypeOf(typeof(Project)));
  controller.DisplayNewProject();
 }
}

  • In SetUp() method - Create the mock objects
  • In each test, set up expectation for this spesific test
  • In TearDown() method - Verify() that the expectation were met.

This makes sure that I won't forget to call Verify() and miss a failed expectation.

* This is one of those rare projects where all the documentation you need is on the front page, and using the library is super easy. One of those things that you just never thinks about. Very happy with it.

time to read 2 min | 254 words

I've found myself stuck trying to design a new UI for NHibernate Query Analyzer. The problem was that I was determained to use TDD to do it, and I just couldn't see how I can do it properly. Anything that I came up with was quite absurd in its complexity, both to test and to write. I tried several approached, and read quite a bit about MVC. But I still got to the point where I'd a displaying UI, and no clear distinction what goes into the View and what goes into the Controller (at least I managed to define what belong in the Model, that should count, doesn't it?).

Then I tried to do it in the Test First approach, with no previous design, I choose a simple goal, a user should be able to create a new project, and then just coded a story in code, and then I went to the unit tests and coded the tests for the functionality that I needed. Only then I wrote the code that actually did something beside testing.

Working this way, the final connecting of the code was very easily done. Now what I need is a simple set of forms which are databound to the objects that I'm displaying, and that should be be it. I've a lot more stories to write, and it should be interesting how I can manage to test "user run a query and get an object graph" story.

FUTURE POSTS

No future posts left, oh my!

RECENT SERIES

  1. Production Postmortem (52):
    07 Apr 2025 - The race condition in the interlock
  2. RavenDB (13):
    02 Apr 2025 - .NET Aspire integration
  3. RavenDB 7.1 (6):
    18 Mar 2025 - One IO Ring to rule them all
  4. RavenDB 7.0 Released (4):
    07 Mar 2025 - Moving to NLog
  5. Challenge (77):
    03 Feb 2025 - Giving file system developer ulcer
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats
}