Effective Unit Testing: best practices

[Yvette Schat]

Hello Lasse,

I enjoyed your book 'Test Driven:...' it brought me up to speed with
a crucial project and I read it + followed the examples in less than a
day :-)

This was some time ago...now I'm now leading a team and I would
like to know from you how, as an expert, you would to best explain
convince the team members what unit testing is about and how it is
best applied...

Thank you,

Yvette

[David Sachdev]

I am curious to know people's thoughts on Test First/Test Driven development versus attempting to achieve good code coverage? Do you feel that Test First development lets you strategically architect out what you are trying to develop, or do you find it limiting? I find that I prefer to test simultaneous with development as opposed to a test-first approach. I'm am curious to know other people's practical take on this.

[Lasse Koskela]

Yvette Schat wrote:now I'm now leading a team and I would like to know from you how, as an expert, you would to best explain convince the team members what unit testing is about and how it is best applied...

Of course the best way would be to buy a stack of books such as Effective Unit Testing

Seriously, there's a couple of different approaches to teaching programming skills in general. One can try to explain concepts and convey their importance using examples. That's essentially what books are all about. Another option is to put the goal of teaching aside and let other programmers observe how you work – not in a classroom or conference hall context but in the grease-on-hands, deep-in-the-actual-code-base context of the work you're getting paid to do. The paradox here is that you can't teach the other person anything. Not really. It's actually the learner who chooses to learn from you and chooses what to learn from you. Of course you can influence the outcome with your behavior and conscious choices – for instance by driving conversations to certain topics – but in the end we all choose for ourselves what we see and what we make of it.

Now, what I would recommend you to do is to do both. Get some books, print out some articles, organize a training class, invite a well-known speaker. These are all good ways of creating reminders, creating opportunities for people to choose to become interested. Once somebody has a spark, has the interest, their curiosity facilitates the kind of learning that can happen when you put two people to collaborate around a shared problem or task. If one of those two people is an experienced test writer, great. If neither has much experience with what they're trying to learn, that's great too – certainly much better than both individuals trying to struggle through alone.

[Lasse Koskela]

David Sachdev wrote:Do you feel that Test First development lets you strategically architect out what you are trying to develop, or do you find it limiting?

I'll share my thoughts on this. First of all, I don't see TDD as a strategic way to architect a solution but more like a way to help me be systematic and focused. Working test-first definitely helps me produce working designs that are modular and fit for purpose. What it limits, for me, is the unwanted things like spending two hours to create a design that's so-and-so.

J.B. Rainsberger makes a nice analogy between TDD and the brakes in your car. He says you don't have brakes in your car so that you can stop. Instead, you have brakes in your car so that you can drive fast. The point is that TDD makes you think about what you're doing and while it may feel like you're going slow because you need to write all those tests, it's the very presence of those tests that allows you to keep writing code as fast as you are. Without the tests and the thinking that leads to those tests, you'd spend a lot of time reading the code over "one more time", "just to be sure" that you haven't broken anything and aren't about to break anything.

TDD is also definitely not the only way to get that outcome and I don't test-drive my code 100% of the time. For instance, writing a test upfront requires the ability to imagine a design that would work. If I'm integrating with an API I don't know, how could I imagine a valid, working design? In such situations, I tend to first hack around with the purpose of learning what I want and then either 1) backtracking a bit and test-driving the code (now that I know how the API works), or 2) adding tests around the hacked-together prototype. When I end up doing the latter, I almost always end up regretting that I didn't test-drive it from scratch. I still do it every now and then. How stupid of me...

By the way, when you say this:

David Sachdev wrote:I find that I prefer to test simultaneous with development as opposed to a test-first approach.

What do you mean by "simultaneously" testing and developing? To me, writing one test, making it pass, writing another, making that pass, etc. is already quite simultaneous and without clear checkpoints along the way I don't feel like I know where I am.

[Yvette Schat]

Hello Lasse,

Thanks!

How would you rebut the counter argument that tests need (to much) maintenance of their own?

Kind regards,

Yvette

[Lasse Koskela]

Yvette Schat wrote:How would you rebut the counter argument that tests need (too much) maintenance of their own?

Probably by pointing out that tests that feel like a burden to maintain or the code they're testing haven't been refactored enough.

Unit tests should be small and focused, which means that they're only interested in a very specific behavior or interaction. That would also mean that those tests shouldn't break unless the specific API's they're interested in are changed.

Besides, which would you rather maintain - a code base with too many tests or one with too few tests?