Community Blogs

The book of never ending production is now actually near the end. the projected print date of “Art Of Unit Testing” is now April 30 and I’m happy to see the Amazon page for the book already has one review of the early access version (though he totally destroys my spelling and book formatting abilities , he likes the content, so I’m happy) Read More...

It’s time to re-examine where things stand in our little niche. This should be interesting, if enough people answer – so please answer (you need flash).   Read More...

A move I’ve been pushing for a while now has finally come through today – Helping to bring unit testing into VB.NET. This is something I strongly believe in: VB has been kind of left behind with the range of latest alt.net related frameworks – mostly because they are C# specific. That means that some of them if not most, that use mambda expressions or anonymous delegates, are less approachable to the larger VB community (VB is missing some key functionality in that space, but even if it did have that functionality, I think the new API we are bringing is easier to grok). We're announcing today a new version of Typemock Isolator (5.2). One of the coolest features in the new version is the inclusion of a new VB .NET unit testing API . This...

Table of contents Introduction Setting the stage Defining the initial user story Limiting, and splitting the user story Finalizing the user stories Organizing user stories Summary Introduction I think I speak on behalf of almost any software developer, when I state that estimating a piece of software is hard. I dare you to count the times, where someone has asked you the question "How long time will it take?". This very question is really unfair, because it undermines everything we stand for as software...( read more ) Read More...

The discussion on the future of unit testing for the masses has shifted from the standard “if they are too stupid to learn it, we don’t want them” to “TDD without good design will make really bad tests”. and this is a good thing. it’s a good thing because it secretly implies that if you could write Good Unit Tests, regardless of design, then teaching design as a separate thing should not pose a problem. Discussion so far: Unit Testing Decoupled From Design == adoption Goodbye mocks, Farewell stubs But first, let’s make one thing clear: TDD is NOT Unit Testing. My previous post was not “TDD decoupled from design==adoption”, it was “Unit testing decoupled from design == adoption TDD is (technically) about when you write the unit test. You can...

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...