TDD

Upcoming talks

Hadi Hariri — Wed, 09 Sep 2009 12:29:56 GMT

Start of the “conference season” again and I’ll be doing a tour of a few countries and places. Hope to meet up with some of you at some place and time. This time I’ll try and have all sessions ready so I can spend my time more productively at the bar/restaurant

- 21st to 25th September at BASTA! in Germany. Talks on ASP.NET MVC, jQuery, TDD, Design Principles.

- 27th to 30th September at Entwickler Konferenz in Germany. Talks on ASP.NET MVC, TDD.

- 12th to 13th October at DevReach in Bulgaria. Talks on ASP.NET MVC, Design Principles.

- 16th to 17th October at TTT/CodeCamp in Tarragona. Talks on MEF and Design Principles.

- 18th to 21st October at SDC in The Netherlands. Talks on ASP.NET MVC.

- 29th October at Micrsoft in Madrid. Workshop on Design Principles (Link available soon)

I’ve also pre-recorded 3 sessions for an online virtual conference on ASP.NET MVC, jQuery and Mocks, all in Delphi Prism and it’s happening right now on CodeRage

Additional code just for testing

Hadi Hariri — Sun, 08 Feb 2009 12:06:36 GMT

Take a look at this code:

   1: public class ClassToTest {

2:

   3:     public void MethodToTest()

   4:     {

5:

   6:         IDAL dal = new DAL();

7:

   8:         int discount = dal.GetDiscount();

9:

  10:         if (discount > 10)

  11:         {

  12:             // Do something

  13:         }

14:

  15:     }

  16: }

The tight coupling to DAL just stands out like a sore thumb. One consequence of this tight coupling is that it's hard to test if we don't have an underlying database setup with correct values. Forget about testing this while taking a shower, unless you have a habit of taking your SQL Server box to the bath tub with you.

Take a look at the following approach to making this code testable without having a database:

   1: public class ClassToTest {

2:

   3:     public void MethodToTest()

   4:     {

5:

   6:         DAL dal = new DAL();

7:

   8:         #if testing_in_shower

   9:         int discount = 3;

  10:         #else

  11:         int discount = dal.GetDiscount();

  12:         #endif

  13:         if (discount > 10)

  14:         {

  15:             // Do something

  16:         }

17:

  18:     }

  19: }

Are you still here? Didn't you just fall off of your chair, not knowing whether to laugh or cry in anguish? It's just plain wrong isn't it? Code Smell just takes on a whole new dimension (and consistency?). Something like this shouldn't be done for many reasons. It makes our code testable but it's wrong.

Introducing code for testing purposes

The reason I bring this up now is because in the past 2 weeks I've seen a few references and examples of introducing code just for the sake of testability. Two weeks ago I was skimming over an article that was explaining unit tests. The class the author was trying to test had a dependency that was causing issues during his tests. The solution offered was to introduce a new constructor and inject the dependency in. In our case, the ClassToTest would like:

   1: public class ClassToTest {

2:

   3:     public ClassToTest()

   4:     {

5:

   6:         // Initialize some stuff

7:

   8:     }

9:

  10:     public ClassToTest(IDAL dal)

  11:     {

  12:         // Initialize some stuff

  13:         _dal = dal;

  14:     }

15:

  16: ....

Now that's great. The problem is that the author left both constructors in there, emphasizing that one is for testing purposes and the other for production code. Why that's wrong I'll get to in a moment.

The other day, Scott Hansleman made a blog post on testing some code that had a dependency on the current principal. His solution was to inject IPrincipal into various methods of the Controller, where Controller is in the context of an ASP.NET MVC Controller. Personally I don't agree with the solution but that's another subject (and another post on a different approach I have in the backlog for the same scenario). However, injecting the dependency seemed valid enough. Later on he updated the post with the following:

UPDATE: Phil had an interesting idea. He said, why not make method overloads, one for testing and one for without. I can see how this might be controversial, but it's very pragmatic.

[Authorize]

public ActionResult Edit(int id)

{

return Edit(id, User); //This one uses HttpContext

}
[Authorize]
public ActionResult Edit(int id)
{
    return Edit(id, User); //This one uses HttpContext
}
You'd use this one as before at runtime, and call the overload that takes the IPrincipal explicitly for testing.

The same thing has happened as in the case of an overloaded constructor. Code has been introduced into the base just for the sake of testability. In the previous case it was a new constructor, and in this case, a new method.

Why is this wrong?

Introducing code just so that you can test it is wrong for several reasons, including an increase in noise, decrease in readability and more importantly, permitting the possibility of production code that will not be tested. It might seem improbable at first, seeing that the overloaded versions always call the base ones, but as your code base grows, by allowing this habit, you can promote it to other structures such as conditionals, switch statements, etc, and not limit it only to methods or constructors. Then you'll start initializing values that only make sense in tests and gradually your code starts to smell more and more. To top it off, you can throw in some compiler conditional that rips those parts of the code out from the production version.

Code should also serve as documentation. The cleaner you make your code, the less noise and redundancy you add, the easier it is for others to understand and maintain.

Conclusion

Being pragmatic is good, but don't do it at any cost. Try and not introduce code into your code base that is there exclusively for the purpose of testability (and no, dependency injection is not only for testability). Anything that has to do with testing, keep it where it should be, in the test assemblies. Having overloaded methods or constructors, mocks or stubs in your code base is just as bad as having compiler conditionals in your code for testability. If you run into issue where your code is hard to test, step back and re-think your design. Maybe the problem you're facing now that's impeding your tests is actually a can of worms waiting to be opened. And the sooner you open it, the better. That's one of the great advantages of Test Driven Development.

Is it time to rename TDD?

Hadi Hariri — Sat, 07 Feb 2009 18:05:30 GMT

Just reading a comment on Uncle Bob's blog by a guy called Ted.

What’s with this whole TDD/SOLID and Podcast stuff?

Just because you practiced TDD does not make your code clean nor high-quality.

Let’s face it, most TDD practitioners are “DEVELOPERS”. You are not “QA”, “TESTER”, “SDET”. What do you know about various testing techniques, testing principles, testing metrics, how to test, etc?

Do our field a favor TDD-er, do the following:
How We Test Software at Microsoft

Go to MS and apply for SDET position (or Google)

Read more books about Software Testing

Ask yourself if you wrote great TDD code or not

Now for the last question, if the answer is “Yes”, then you’re a Tester. If the answer is “No”, then you’re a developer. And obviously, if you are a developer, you suck at TDD.

It’s just how the brain is wired or perhaps it’s in your training. Developers are almost always bad testers, vice versa.

Maybe TDD should be renamed "Coming up with a good design by first trying to use my code Driven Development". There is an overwhelming amount of information regarding Test Driven Development and yet, still, STILL, people think it's about testing.

Fluent NHibernate

Hadi Hariri — Fri, 19 Dec 2008 09:10:09 GMT

I've recently started a new internal project and decided to use NHibernate. I've used NHibernate previously on several projects and one of the things I didn't like was the mapping. That's where you waste the most time and for refactoring it sucks. Every time you need to create a new property or change an existing one, you need to make sure you've updated the XML mapping file.

I had decided to check out the fluent nhibernate project that I had heard about. I thought even though it didn't do away with the mapping, at least you had it in code, so you could easily refactor and do away with some of the mapping errors you initially face. Luckily before I started this project, I ran across Ayende's post on the new Auto-Mapping features of Fluent NHibernate, and I must say, I've been blown away (my twitter followers are probably starting to get sick of me).

I'm now able to do true TDD without having to touch a line of SQL or XML. The only reason I open up SQL Management Studio is to just make sure that the automapping is working correctly, and it is. It handles one to many, many to one, many to many, anything you could think of. And the beauty of it is, that if there is something it can't handle, you can still map it yourself in code.

Take this class:

   1: public class Customer

   2: {

   3:     public virtual int Id { get; set; }

   4:     public virtual string NameFirst { get; set; }

   5:     public virtual string NameLast { get; set; }

   6:     public virtual ICollection<Invoice> Invoices { get; set; }

   7: }

8:

   9: public class Invoice

  10: {

  11:     public virtual int Id { get; set;}

  12:     public virtual string Number { get; set; }

  13:     public virtual DateTime Date { get; set; }

  14:     // Rest omitted...

  15: }

The only thing I have to do, to configure this is:

   1: persistenceModel.AddEntityAssembly(assembly)

   2:     .Where(entity => entity.Namespace == "iMeta.Example.Domain.Entities" && entity.GetProperty("Id") != null)

   3:     .WithConvention(convention => convention.GetForeignKeyName = p => p.Name + "Id")

   4:     .Configure(config);

That's it. The only thing that I don't seem to know how to handle yet is components. For now I'm adding some manual mapping (something I'm missing?). So for instance, if Customer has an Address property like so:

   1: public class Address

   2: {

   3:     public virtual string Street { get; set;}

   4:     public virtual string City { get; set;}

   5:     public virtual string State { get; set;}

   6: }

and the corresponding property on Customer:

   1: public class Customer

   2: {

   3:     ...

   4:     public virtual ICollection<Address> Addresses { get; set; }

   5: }

the resulting configuration would be (line 4 is new):

   1: persistenceModel.AddEntityAssembly(assembly)

   2:     .Where(entity => entity.Namespace == "iMeta.Example.Domain.Entities" && entity.GetProperty("Id") != null)

   3:     .WithConvention(convention => convention.GetForeignKeyName = p => p.Name + "Id")

   4:     .ForTypesThatDeriveFrom<Customer>(map => map.Component<Address>(t => t.Addresses,

   5:                                                                          c =>

   6:                                                                          {

   7:                                                                              c.Map(t => t.Street);

   8:                                                                              c.Map(t => t.City);

   9:                                                                              c.Map(t => t.State);

  10:                                                                          }))

  11:     .Configure(config);

If you don't add this, it will create a table in the database of type Address and reference the customer with a foreign key, as opposed to flattening out Address to fields in the Customer table.

If you combine all this with a call to SchemaExport (Nhibernate Tools namespace), you can have it create your database schema for you. Do this in your tests and you no longer have to worry about cleaning up your database before each test or creating scripts that need to be run as part of your CI build. Very cool!

Naming tests, once again

Hadi Hariri — Sat, 20 Sep 2008 06:33:41 GMT

I'm coming across a lot of tests with names like this:

AddEmployee_Should_Pass_When_Not_Duplicate() {.....}

AddEmployee_Should_Fail_When_Duplicate() {....}

For the purpose of this post, I don't care about anything other than what's in bold and red.

The word Pass in there is completely irrelevant and useless. The word Fail is just mind-blowing. What should fail? The test? What if the test passes? Does that mean it has really failed? Or when it fails it means it passes?

Now we all know what Fail means here. It means the test will pass but the call will fail. But it doesn't indicate to us what failure consists of and therefore it's not adding information. Someone looking at the test cannot validate it.

When naming, indicate what the test is trying to validate, not what the outcome is; the outcome is already known: pass or failure.

Something along the lines of Add_Employee_Should_Throw_Exception_When_Employee_Already_Exists would add substantial information for the person reading your test to validate the functionality. But more importantly, when the test fails, they would know what has failed and have valuable information for debugging.