Jeremy D. Miller -- The Shade Tree Developer

The semantics of how you write a unit test, the basic syntax, or Domain Specific language of how we write

I agree with jason. Tests using mocks will always be as complicated as the system that is being tested. As someone who's seen your code snippet for the first time, I still had to make an effort to understand it.

My approach to increasing readability is by using code comments, both as headers of test methods describing what is being tested and how (if it is really complicated) and also inline comments for certain things which may not be obvious.

I have the same problem with forgetting what some old test code was all about ("old" in my case means few months ) and code comments do help. But I support your effort if you think it helps.

It's hard to say after a first glance. The Given...WhenExecuting...TheInteractionShouldBe...Then is easy enough to follow but the stuff inside each of these blocks isn't right off the bat. But I do get the impression it would be easy to get used to.

The thing is that it looks even more magical than the AutoMockingContainer. Having said that, I like the magic of AutoMockingContainer so I could get used to what you're doing pretty easily. It's nice that I don't even need to retrieve a reference to the mocked objects directly. Others may argue it's hard to figure out what it's calling all these methods on in the TheInterfactionShouldBe section.

Side note: I find using the Record and Play methods in Rhino.Mocks goes a long way to adding readability:

using ( _mocks.Record )

{

   // Set expectations

}

using ( _mocks.Play( ) )

{

   // Replay code

}

Still requires knowledge of mocking but it's dead simple to see how the Replay/Verify code is separated.

I think C# is getting in the way: all of the <> () delegate ...

"Yoda syntax" - Genious wit!

I think the new approach is very stylish but not that readable. I do something like your old code but with more refactors for readability. Here’s how I would refactor it.

1. Rename _command to subject. It’s odd that there’s a _systemUnderTest there already n’ it’s mocked. The first line in my BehaviourTest is the subject (or sut declaration).

AddNamedFragmentCommand subject;

2. Extract method givenTheFragment(string name). I use assume instead of given but at the end it the same, setup a stub for the test.

3. Extract method expectToSave(Fragment fragment).

4. Extract method expectToRefreshTreeNodes().

5. Extract method expectToStartEditing(Fragment fragment).

6. Extract method expectToOpenScreen().

7. Extract method assertThatExistFragment(string name).

Then all those methods go into regions and all mocks into another region called main cast and the test would look like:

public class AddNamedFragmentCommandTest : BehaviourTest {

private AddNamedFragmentCommand subject;

#region main cast

#region fixture setup

#region given

#region expectations

#region assertions

[TestMethod]

public void AddNamedFragmentCommand_adds_new_Fragment(){

            string name = "Fragment1";

Fragment fragment = new Fragment(name);

givenTheFragment(name);

expectToSave(fragment);

expectToRefreshTreeNodes();

expectToOpenScreen();

subject.execute;

assertThatExistFragment(name).

}

}

*: I hide ReplayAll in the last expectCall. Shame on me, but takes away the noise from the test. The VerifyAll() call is hidden in the [TestCleanup].

I totally agree with jason that the new syntax is a bit harder to read but easy to understand since it "reads" as if you were expressing it verbally.  However, like Chris said, C# does "get in the way" since, like you said, "it's not Ruby".

For my tests, I'm currently using the AutoMockingContainer that's part of Rhino.Testing and it's working pretty well for me in conjunction with the Record and Playback syntax.  For example, here's  snippet:

using (Record)

{

   PatientEntity patient = Mock<PatientEntity>();

   PatientEntityDTO dto = Mock<PatientEntityDTO>();

   info.PatientEntity = dto;

   IEntityTranslator<PatientEntityDTO, PatientEntity> translator =

       Get<IEntityTranslator<PatientEntityDTO, PatientEntity>>();

   Expect.Call(translator.ConvertTo(dto)).Return(patient);

   IFormXmlProvider<PatientEntity> xmlProvider = Get<IFormXmlProvider<PatientEntity>>();

   Expect.Call(xmlProvider.GetFormXml(patient, null)).Return(eventXml);

   LastCall.IgnoreArguments();

}

My Get<T>() method is part of my AutoMockingFixture class that handles all the "dirty" syntax needed to create mocks or get items from the container.

Granted my tests are probably not as complex as yours.

I was showing this post to a coworker and I did a bit more of refactor. Here’s the result:

[TestMethod]

public void AddNamedFragmentCommand_adds_new_Fragment(){

 givenTheFragment(name);

 expectToSave(fragment);

 expectToRefreshTreeNodes();

 expectToShowInScreen(fragment);

 subject.execute();

 assertThatExistFragment(name).

}

You seem to be using integration and interaction interchangeably in this article, is that intentional?

I don't find the new one particularly readable. Its probably better but still not that understandable and Mike Suarez's solution seems to me to be more readable.

@Jeremy

I don’t actually refactor into those given/expect/assert methods. I write then in Pseudo Code style, not as comments (like in Code Complete) but as real functions and Resharper generates then. The extra effort is moving the pack into a region but it pays off in readability and Test as living documentation. What you see in a class after collapsing all is something like:

[TestClass]

public class AddNamedFragmentCommandTest : BehaviourTest {

private AddNamedFragmentCommand subject;

#region main cast

#region supporting roles

#region given

#region expectations

#region assertions

[TestMethod]

public void AddNamedFragmentCommand_adds_new_Fragment(){}

}

*: fragment and name are declared in the supporting roles section.

You can start expanding accordingly your depth interest. If that’s going too far I’m not so sure. A friend recommended throwing the Symetry patterm from Becks new book. Plus I’d like to add the “treat your tests as your production code” + Custom Assertions from Meszaros’s . Anyways I’m a n00b and I tend to go too far. So it’s a good sign that you like my approach as more readable but it looks like is not worst the effort. Thanks

Yeah I like that too, testing by intention at the high level seems to me like a good way to go.