Comments on: Unit testing tricks: Look ma, no setters!

By: Johannes Brodwall

Johannes Brodwall — Wed, 17 Jun 2009 21:42:40 +0000

True. The reason they ended up as protected is that that's what happens if you just do "Ctrl-1" in Eclipse. ;-)

This example requires a no-arg constructor, but if Account only had, say, a constructor "Account(String accountNumber)", you could just do new Account("12345678901") {{ and the rest would be the same.

By: jhannes

jhannes — Wed, 17 Jun 2009 14:42:40 +0000

By: Baard H. Rehn Johansen

Baard H. Rehn Johansen — Tue, 16 Jun 2009 19:47:02 +0000

If the test-code is in the same package as Account you could use package-private fields instead of protected fields. In your example, Account also requires a no-arg constructor.

By: Filip van Laenen

Filip van Laenen — Mon, 15 Jun 2009 08:44:11 +0000

I think it would give less violation since it would only be a setter (a protected variable is basically a proetcted getter and a setter), and at the same time less confusing.

By: jhannes

jhannes — Mon, 15 Jun 2009 07:45:05 +0000

Yes. But I thought that'd give me as much violation of encapsulation, but with more code. If the setters were to be used by other code, I would've gone that way, though.

By: Filip van Laenen

Filip van Laenen — Mon, 15 Jun 2009 07:19:04 +0000

Have you considered adding a protected setter instead?

By: Sergio Bossa

Sergio Bossa — Mon, 15 Jun 2009 06:59:34 +0000

Hi Johannes,

it's a neat trick, but I still prefer to separate the domain object interface from its concrete implementation, and than add all required setters/getters to the latter.

By doing so, if you program by interfaces your domain code will only see methods from the interface (so no breaking encapsulation), while you will be able to still use setters/getters in your test code (nothing bad about that, tests are there for testing actual implementations).

Cheers,

Sergio B.

By: Kristian Nordal

Kristian Nordal — Mon, 15 Jun 2009 05:40:56 +0000

I like the “trick” with anonymous subclass + initialized block, and use it often. It's great when initializing collections.

I'm not sure about making the fields protected though. I don't like it when my tests affect/dictate visibility/accessibility.

By: vidar

vidar — Mon, 15 Jun 2009 04:14:41 +0000

Nice. I have used a similar technique creating dummy classes that extends the class under test and override methods instead of using mocking. Next time I will definitely consider your approach.

The “dummy class” technique is described in Robert Martin´s book Working Effectively with Legacy Code.

By: jhannes

jhannes — Sun, 14 Jun 2009 18:19:15 +0000

The impact on the class under test is something that concerns me. In this particular case, we were debating whether to do this or use a inner builder class. They both felt slightly smelly, but at least this approach has the least code.

When the problem starts to scale, I might consider builders, structs, introducing setters or something else. But it seems like a lot of extra code to write for the size of the problem.

There's a lot of tools in the "object initialization in test" toolbox. I'm still not thrilled with any of them.