Comments on: To Assert or Not To Assert

By: Can you spot Java Puzzler in this snippet? at JAW Speak

Can you spot Java Puzzler in this snippet? at JAW Speak — Wed, 30 Sep 2009 20:00:10 +0000

[...] and I saw this in a test with a particularly ugly constructor with 12 parameters. We were following Misko’s style of “use nulls in tests, but not in production code” and thus that Boolean [...]

By: Should we enforce constructor args?! « Journal of a software dev

Should we enforce constructor args?! « Journal of a software dev — Sat, 27 Jun 2009 10:54:07 +0000

[...] written and the information surrounding good OO and unit testing was, anyhow I came across this post which made me think about whether we should be asserting the collabarators in the constructor or [...]

By: Giorgio Sironi

Giorgio Sironi — Sat, 30 May 2009 09:23:42 +0000

You say you can write a test for the factory that will asserts that non-null values are passed to the constructor. But how can you write such a test? I know Guice will take care of, but the contract of my factories is ‘you call create*(), I return an object’. The object collaborators are private field references and I cannot access them to see if they are null. Maybe a method verifyNull() on the created object can do the work, but to me it seems ugly.

By: Craig McDonnell

Craig McDonnell — Thu, 05 Mar 2009 23:04:24 +0000

From experience, defensive programming has helped me avoid long debugging sessions on many occassions. I’m not sure I can agree with this post but it’s certainly food for thought.
I’ve been considering using the Findbugs annotations and perhaps the @NonNull annotation could be of use here.
With this annotation we can enforce the null check for client code under /src but not /test? -This could even have the added benefit of moving the constraint check from run-time to compile-time.

By: mgira

mgira — Wed, 04 Mar 2009 10:17:42 +0000

Hi Miško,first, let me say that i really enjoy reading your blog!Back to topic:If you want to test Objects in an “inconsistent” state (i.e. not completely initialized), maybe setter injection would be a more flexible approach.

By: Chris Martin

Chris Martin — Sat, 21 Feb 2009 07:49:13 +0000

Because, I never want my entities in an invalid state, I’d prefer to keep the asserts in place and use a simple Object Mother (provide default stubs/mocks), if not a full on IoC, for testing.

By: Lee Campbell

Lee Campbell — Tue, 17 Feb 2009 10:47:48 +0000

Love the blog, and like other disagree with you on this case. If the class was dependant on abstractions and not concrete classes then testing would not be a problem. You could have the asserts and in your tests just use null objects or a mocking framework.

By: Jose M Beas

Jose M Beas — Mon, 16 Feb 2009 01:35:53 +0000

Dear Miško,Although I always agree with your opinions, I'm afraid I cannot be with you in this case. I also think that your example is wrong because (IMHO) if you can call the constructor with nulls or even NullObjects, that smells to those collaborations are optional, so you can simply take them away from the constructor and put setters for them (or use the Builder pattern). In both cases you can keep the asserts for those properties that never can be null. Actually you should move them to the setters (or builder methods).And also I'm not sure what you mean when saying (in one of the comments you made later) that "it is not the responsibility of the class to worry about its construction". You mean, in a dependency injection container context, that it is the container's factory responsibility to create the objects? But how can this creation strategy affect to the assertion of non-null arguments in the constructor of a class?Best regards,JMB

By: Pat Maddox

Pat Maddox — Fri, 13 Feb 2009 18:04:47 +0000

I think it would make a lot more sense to leave the constructir asserts in place, and use mock objects or a test data builder to simplify the tests.

By: Adil Aijaz

Adil Aijaz — Fri, 13 Feb 2009 07:33:59 +0000

argh .. the pseudocode got messed up