Comments on: TDD: Test only constructors

By: miluch

miluch — Wed, 06 Jan 2010 09:38:38 +0000

I also bumped into invariants checking in constructor/factory dilemma.

The main drawback of test-only constructors/factories is that you can not guarantee that none of your colleagues will use them in production code !!!

On the other side, calling production-available (real) constructors/factories in your test can be very painfull…

Invariant checks inside User.CreateUserFor(headers) are quite trivial so it does not seem to be the case but imagine the scenario when class invariants are very complex and hard to satisfy.
Let’s say you want to create triangle object, feeding it’s constructor with 3 angles.

Triangle(int angle1, int angle2, int angle3)
For triangle all interior angles total to 180 degrees.
This invariant check can be done in constructor itself or in Factory..

This approach seems to be very attractive – you will always work with valid triangles, but as i mentioned above it kills testability:
To test any of triangle behavior (for example checking if triangle is right-angled) you first need to instantiate it feeding it with correct angle values.
For triangle example it still does not seem to be the case, but in more complex scenarios instantiating object to be tested can be quite hard.

So having factories/constructor for tests can be quite tempting but how would you enforce your colleagues to not call them in their code ?
By writing appropriate comments (javadoc)?
By using access level modifiers?

By: Coding: API readability/testability at Mark Needham

Coding: API readability/testability at Mark Needham — Fri, 09 Oct 2009 14:25:43 +0000

[...] a month ago or so I described how we did some work to ensure that we were calling a class the same way in our tests as… and while I think that was a good choice in that situation we came across a similar problem this [...]

By: Nat

Nat — Sun, 20 Sep 2009 21:33:46 +0000

It looks to me as if your User class has too many responsibilities. One is to define how User objects act (part of your application's domain model). The other is to parse header fields that have come from some message or HTTP request or somewhere and interpret how they are used to define a User.

If you move the latter responsibility out of the User and into a package of classes that define your app's network protocol (for example), then you only need one constructor for the User that is used by both the network protocol package and unit tests.

By: Sai Venkat

Sai Venkat — Mon, 14 Sep 2009 20:15:01 +0000

Wow… And I wonder why people want to try to use things like InternalsVisibleTo or reflections to test this? I think your solution is way more elegant that those

By: Sai Venkat

Sai Venkat — Mon, 14 Sep 2009 20:12:36 +0000

Think I ran into the same situation when we were writing some Http Handlers based on Asp.Net in our project. In application, the query parameters are passed to a factory which creates object based on the request. In test, we used a QueryParametersBuilder which will construct this for us.
I think it is similar to your approach of having a UserBuilder which abstracts the process of creating the user from the request. It does leak some implementation but I think as @Dcam has pointed it the part of contract…

By: Uday

Uday — Sun, 13 Sep 2009 13:45:57 +0000

If it was a Java code, i would have preferred using reflection to create the User object in UserBuilder without changing anything in the current User class.

Not sure if it is feasible in C# (assuming the code you mentioned is written in C#)

By: Darshan

Darshan — Sat, 12 Sep 2009 03:49:46 +0000

You can make all your "just for test" methods internal and then access in your test code by using assembly:InternalsVisibleTo attribute.This is tedious but is better insulted then your solution.

By: Mark Needham

Mark Needham — Sat, 12 Sep 2009 03:46:53 +0000

@Robert – I'd have said that hiding the creation behind the builder as you suggest in 2) would make it less necessary to have the test constructor?

I guess in our case we didn't have specific tests around the real constructor although it was being called in our acceptance tests so it was still being tested somewhere.

By: Robert Watkins

Robert Watkins — Sat, 12 Sep 2009 03:37:51 +0000

Some thoughts:

1) There's nothing wrong with adding a test constructor – as long as you have tests that also test the real constructor. Some objects (particularly key domain concepts) get instantiated a lot by test code – making that easier and cleaner will help the _other_ tests.

2) You can help clean up the leaking by using a builder to create the name value collection. If the same builder is used in the production code, all the better.

By: Ollie Riches

Ollie Riches — Fri, 11 Sep 2009 20:46:36 +0000

Surely adding anything to the 'production code' for a testing purposes is a code smell at the minimum and in the worse case demonstrates that the code is not completely testable – can't be decoupled so therefore can't be tested…