One way out is to create a parameterless constructor on the class which is only used for testing. Not at all nice, but sometimes necessary to create that first seam.

A candidate I was pair interviewing with introduced me to something which may prove preferable in these cases – the Microsoft serialization library has a method which will initialize a class without calling the constructor:

FormatterServices.GetSafeUninitializedObject
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.formatterservices.getsafeuninitializedobject.aspx

This way you don’t have to modify the code!

I would only ever advise using this if your only other sensible option would be to override the constructor. Hopefully once you have your tests you would be able to confidently refactor out the problematic code.

Getting Started With IronRuby And RSpec
BDD-style feature tests using IronRuby and RSpec/Cucumber
Example of using ironRubys mini_rspec library

Yeah, so game on I think. If you’re not sure why I’m so excited by the prospect of doing this I suggest you have a look at some BDD examples using RSpec and Cucumber. In my mind it’s light years ahead of what we can currently do with the .Net framework.

Whilst I really like the idea of actually doing this I do have some reservations:

• You still have to compile your .Net code so no enormous time savings.
• RSpec takes some time to get going as well, which is not a problem if you’re doing a large run but might be quite annoying otherwise.
• Have no idea how you’d be able to get test coverage reports (I’m sure some bright spark will get this working soon enough).
• Not exactly sure how debugging would work (stepping into your .Net code from an RSpec test).

On a side note and forgetting about the instability of it for a second I was really impressed with IronRuby and the CLR interop so, er.. *gulp* well done Microsoft!

I originally started by making an effort to write my tests method names as sentences starting with “should” (e.g. should_set_active_status_to_false_when_status_updated), but having used the “Given, When, Then” format for our automated acceptance tests I’ve been trying to move more in this direction.

For a start, I’ve being using the Visual Studio solution explorer to help. Previously tests would be organised something like this:

Which I have replaced with this:

As you can see I’m using folders and file names to help give the tests context. One major advantage of this is as the tests are less coupled to the implementation of the system under test (SUT) any changes to the implementation are less likely to require moving tests around so the intent remains intact. The other obvious advantage is the intended behaviour is much clearer.

The next thing to show you is the tests:

The nice thing here is the namespace is taken from the folder and the class name from the file name so I’m getting a nice convention (even if it is being obfuscated by C# scaffolding). In this example I’m still sticking to the “should” convention but below I went for something a bit different:

So this is a little different because the conditions are more specific. There’s another class for non view direct users so I split them up, partly so the test method names needn’t be so long but mainly because it’s easier to understand what’s going on. Purists may feel uncomfortable with my relative lack of a standardised syntax, but the most important thing to me is it’s easy to see what’s going on and beyond that I don’t particularly care how you say it.

What this really is is a feeble attempt to mimic the elegance you get from RSpec (which we’ve been using along with Cucumber & Watir to write our automated tests). I was thinking today whilst I was playing with this that I don’t just want to mimic RSpec I actually want write my unit tests using RSpec. Excitingly it looks like the DLR and IronRuby will make this possible. Up until now I’d been struggling to think of a really appropriate use of a dynamic language within the .Net context but not any more.

One of the less stated benefits of doing TDD is that it concentrates your mind on the problem.

Recently I was looking at a section of code which was creating a Lucene search string from criteria passed in from the user. I needed to add some new functionality, but it was a bit higgledy-piggledy so following the broken windows principle I decided to refactor it to the builder pattern before I added my new feature.

I ran NCover on the code and it reported 70% coverage which considering what I knew about the history of the system was surprisingly high. I decided there was enough coverage, paired with a colleague and dived in. At first we were doing well. Our changes broke the tests a few times which reassured us about the coverage, but after a while it felt that we were losing a bit of steam. We’d done a lot of refactoring but it didn’t feel like we’d got very far.

Skip to a couple of days later – I’d not been able to touch the code and neither had my colleague who had now been taken off to deal with another project, so I pulled in the other dev on my team who is probably the most fanatical TDD nut I’ve ever met. Immediately he was uncomfortable, he’d quickly spotted the tests were really only integration tests (something I had put to the back of my mind) and got jittery as we continued from where I’d left off. I didn’t like to see him in so much pain so quickly relented and let him write new tests even though I felt it was just going to slow us down, maybe even to the point where we wouldn’t get it finished. However he assured me that although it felt slow now we’d be racing along soon enough.

Not only was he right about that, but as we were doing it the objective was so much clearer. Writing the new tests meant we were forced to really think about each move we made so our refactoring had clear direction. We spent about the same time working on the problem but probably made twice as much progress as my previous attempt and ended up with a proper unit test suite around the code.

Some day soon people are probably going to do away with the need to do TDD, which I think will be a shame as it never ceases to amaze me how many benefits it has. ]]> http://blog.robbowley.net/2008/09/27/tdd-keeps-you-focused/feed/ 0 http://blog.robbowley.net/2008/08/16/rip-nmock/ http://blog.robbowley.net/2008/08/16/rip-nmock/#comments Sat, 16 Aug 2008 21:38:42 +0000 rob http://test.robbowley.net/?p=37 After Mini Spa this year I was fortunate enough to get to chat to Nat Pryce in the bar. He mentioned some interesting projects he’s working on, such as something I think he called “Domainatrix” – a tool you can use to analyse your code to see if it is relevant to the domain. Very nice chap.

Having used NMock (which he helped write) extensively I asked him if anyone was looking after it as there hasn’t been any visible activity for a while. It turns out that Thoughtworks took it over as of release 2.0 but have clearly decided not to support it anymore.

If you’re still using it I highly recommend you start looking for a new mocking tool ASAP.

Stubs

In nMock, if you want to stub some method calls on a mocked interface you have to do something like this:

Mockery mockery = new Mockery();
IService mockService = mockery.NewMock();
Stub.On(mockService).Method("MethodA");
Stub.On(mockService).Method("MethodB");
Stub.On(mockService).Method("MethodC");
...

Which is cumbersome and noisy. In RhinoMocks you can do this:

MockRepository Repository repository = new MockRepository();
IService serviceMock = repository.Stub();
...

…and RhinoMocks will ignore all calls to that interface. This is really nice as you generally only test the SUT’s interaction with one dependency at a time.

Dynamic Mocks

If you only want to test one interaction with a dependency and ignore all others you can create a dynamic mock.

MockRepository Repository repository = new MockRepository();
repository .DynamicMock();
...

All calls to the mocked dependency will be ignored unless they are explicitly expected (e.g. Expect.Call(mockService.MethodA)…..). This is the same as not saying mockery.VerifyAllExpectationsHaveBeenMet() in nMock. It’s always annoyed me that you have to remember to do this in nMock and I much prefer that the default for RhinoMocks is to fail when encountering an unexpected method call.

Raising Events

nMock does not natively support raising events, which is a pain, but there are ways around it (I’ve extended his example to support custom EventArgs which you can download here). With RhinoMocks it’s much simpler. Rather than explaining it myself, check out J-P Boodhoo’s great example here.

Michael Feathers’ book “Working Effectively with Legacy Code” has this to say about it:

“This question comes up over and over again from people new to unit testing: “How do I test private methods?”. Many people spend a lot of time trying to figure out how to get around this problem, but [...] the real answer is that if you have the urge to test a private method, the method shouldn’t be private; if making the method public bothers you, chances are, it is because it is part of a separate responsibility: it should be on another class.”