Community Blogs

I've gotten the chance to visit and consult various companies and I see this all the time: Over specification in tests, especially when doing mocks and stubs . One main reason for that is that people use their stub as a mock object (stubs are fake objects that we will not assert on so that we can test something else). here is a small example from something posted on the alt.net mailing list: [Test] public void Can_Return_All_Plans() { IPlanDao mockPlanDao = MockRepository.GenerateMock<IPlanDao>(); mockPlanDao.Expect(x => x.AllPlans(_fakeAdmin)).Return(new List<Plan>{_fakePlan}); PlanController planController = new PlanControllerForTesting(_mockCommonDao, _mockCommonService, mockPlanDao); ViewResult result = planController...

Here's a sneak preview of the upcoming Typemock Racer product, which I'm currently working on. We should be out in private CTP in a couple of weeks I hope. Typemock Racer tries to solve one huge problem for developers working in multi threaded environments: Detecting code that can result in deadlocks or race conditions. It does this by providing a framework API which you can use in your tests (under NUnit for example), that allows you to execrise your code under test until it finds a deadlock or times out. Here's an example of how you'd use it. Consider the following class which has two methods, that if run by two seperate threads, can result in a deadlock condition: At some point in time the threads could execute such that thread...

It's interesting to see the other mocking frameworks as they grow into maturity. Especially Moq which has been getting loads of new features recently. The latest one is something which makes me feel a bit weird after reading all the things people fear in Typemock Isolator :It seems that  Moq now allows mocking protected fields . What's really interesting is that Daniel has chosen to actively allow this, and hide the feature at the same time, as well as put it under a strict optional request : you have to opt in for each code file where you'd like this ability by adding a special imports statement. So, the questions I have are: What happened to "if it's not testable it's a design smell"? Is this a compromise...

As part of My Book I have a chapter on the challenges of integrating unit testing practices into an organization. One of the sections deals with "Tough questions and answers". In short, what are the tough questions you will have to deal with when introducing unit testing. here are the questions I've come across but I'd love to see if there are some that I am missing. Also, I am looking for great answers and references as responses to these questions. Your comments are appreciated: 1 How much time will this add to the current process? 2 Will my QA job be at risk because of this? 3 How do we know this is actually working? 4 How much time will this add to the current process? 5 Is there proof that unit testing helps? - any other...

This NullObject Factory from Paul is very nice, simple and clean in its design. I really like it and I can see many uses for it, in parallel with working with your standard mocking framework or IoC Container Implementation .   here is a little usage example (last line): var controller = new AccountController( // Class I am testing mockCustomerRepository, // Class I am mocking NullObject.For<ILogger>() ); // Who cares about logging! Read More...

Today was both a good day for e and a bad day for me. Good day because I managed to get a full suite of tests that were somehow failing to work again after a refactoring that got out of hand. Bad - because out of all the tests, one of them failed. Here's the part I'm ashamed of: I was working with a pair, and when we both looked at the failing test, I went out and said "Oh, I think this test is no longer valid. It may just need to be removed". We both knew it was still a valid test, that for some reason was failing. But I was on such a role with making everything work, that test was feeling like a thorn in my thumb that I wanted to get rid of. It was a hard few minutes to convince ourselves to debug through the test and realize...

Not sure how I feel about this particular brand of testing syntax . still, it's good that someone thought this problem through - testing xml serialization attributes. [via the morning brew ] Read More...

As I was looking back and forward on the changing syntax of testing and mock frameworks, it occurs to me that there are still things that need to be solved in the mocking space. many things. It's hard to choose a framework and stick with it because they have different abilities which you are not sure you might need or not later on Each framework has different syntax which is a learning curve and maintainable curve in test code You can't change your mind easily after you choose There is no specified set of known features to be expected. Each one has what it thinks is best.   What if we had an abstract layer on top of our mocking frameworks? Just like ADO.NET is an abstraction layer, and the Data Application block is an abstraction...

We just released the beta of Typemock Isolator 4.2 beta (Previously just named Typemock.NET). You can get it here . Some of the cool new things: Mocked methods will be highlighted in the debugger if you step into them. in the picture below the "DoSomething()" method is being mocked, so stepping through it means nothing. The line around it signifies this status. You can evalutate mocked methods in the deibgger and various watch windows without the original test being affected (so if a mocked method should only return "1" on the first call, even if you evaluate it three times in a watch window it will return "1" in the watch window and also will still work in the test and return "1" You can now mock a non...

The semantics of how you write a unit test, the basic syntax, or Domain Specific language of how we write them, has been relatively stale for quite some years now.  But under the covers, the syntax revolution seems to be brewing, as people try to come up with newer, hopefully better and more readable syntaxes for tests and specifications that become more and more complex as the current Agile community struggles to accept best practices in this arena. I'm guilty of that too, but a recent post by Jeremy Miller prompted me to try and list all the different syntax variations I've come across in the .net and some in java world (not necessarily in chronological order). Most ofthese didn't necessarily catch on as de facto standards, but are real...