Development Central

I’ve listened to a couple of podcasts from Software Engineering Radio, and have been impressed. They have good guests and conduct interesting interviews.

The two I’ve listened to so far are:

• Episode 97: Interview Anders Hejlsberg
• Episode 103: 10 years of Agile Experiences

Definitely worth checking out.

I converted the unit tests on my current project to use Moq instead of Rhino Mocks today.

Daniel Cazzulino gave me the last piece of the puzzle on the discussion group: Mock.Get(theInterface) returns the mock for the given interface instance, allowing me to set further expectations on an object. See the discussion for the reasons I wanted this feature.

The only major issue I ran into in converting the tests was one class that used out parameters on methods. Since Moq doesn’t support out or ref parameters in the current revision (it’s supposed to be in the trunk, though), I created a stub class by hand in a few minutes. Hopefully I can remove that in the near future.

It’s liberating to have no record/replay model. I also find Moq relatively intuitive; with Rhino Mocks, I regularly had to look up how some feature worked.

No one I asked at work had used either library, so I was free to switch. I plan to do a presentation on Moq to the developers in the near future.

Update - October 8, 2008

A new version of Moq is available with support for out and ref parameters! I tested it with out parameters, and it works. You do have to be careful due to closures capturing variables, though - please see the discussion posts.

(Previous article: Mocks: The Next Generation)

Ayende released the new version of Rhino Mocks. I’m still not satisfied with its support for stubbing properties (read-only properties must be handled differently from read-write properties). See this discussion on the Rhino.Mocks group for details. I also don’t like the requirement of BackToRecord/Replay calls to change a previous expectation.

Both of these concerns are addressed by Moq. I had felt that Moq’s ExpectGet syntax was wordy for properties, but now feel that the price for Rhino’s PropertyBehavior (different syntax for read-write properties) is too high. I’m also coming to appreciate the power of Moq’s It.Is syntax (another former complaint).

One downside to Moq is that it currently does not support out or ref properties. Apparently this has been added to the trunk and will be in the next release.

I went back and wrote more learning tests against Moq, handling the same cases as my Rhino Mocks v3.5 tests. These went well, so I tried porting some real-world tests to it. I ran into a roadblock here; see my post on the Moq Discussions group for details. This may be more of a code smell in my tests than a major limitation in Moq, so please don’t take this as a critique of the library.

I tend to get frustrated when using Rhino Mocks, and so far Moq has (mostly) worked as I expected. I think Ayende’s last comment on the aforementioned thread is particularly interesting:

You can use a mock instead of a stub, and only use Stub().

To me, this lends credence to Daniel Cazzulino’s comments that understanding the difference between stubs and mocks is largely irrelevant.

Update - October 6, 2008

See Switching to Moq.

http://www.drexplain.com/press/chm-files-the-page-cannot-be-displayed-error/

It never would have occurred to me that the problem was a folder name that contained “C#".

I’m currently reading Bob Martin’s Clean Code. While I don’t agree with every word, I think it’s a very worthwhile book - even when I disagree, it makes me think. (And most of it’s spot-on.)

The chapter on unit tests talks about classic test-driven development (TDD), and describes a thirty second cycle of testing/coding. This got me thinking about the future of TDD.

One of the issues with testing is the separation of the tests from the code under test. I’m always switching back and forth between two units. Some languages (my boss mentioned Eiffel) already support the idea of “tests” (specifications, contracts, etc.) as integral parts of the code.

Not too many years ago, developers were used to writing code, then compiling it (wait, see if errors), then linking it (wait, see if errors), then (possibly) running a lint checker on it to detect more subtle issues. Modern IDEs show most syntax errors almost immediately. Plug-ins like ReSharper add more real-time diagnostics.

What if the IDE could run tests as we coded? I could start writing a test; as soon as it was complete, a red mark could appear in the margin (failed). I’d then start to write code to make it pass; as soon as that was done, the mark could turn green. Thirty seconds would seem positively glacial.

I can see it.