my experience tells a different story. All TAD tests I have seen have much less value, are much more complex and harder to maintain than tests that result from TDD. TAD tests achieve lesser coverage, are not executed often enough and lead very easily to happy path testing only. With TAD tests people verify their own expectations of the code they just wrote which narrows the scope of tests.

I’ve seen so much TAD tests during the last 12 years with substantially lower quality and less coverage that I just don’t see it as a one-off event or unskilled people issue. Yes, you can design your code to be testable and write comprehensive tests after, but I’ve never seen that to happen. Also, it misses the whole point of TDD, which is a design act, not a testing act.

Maybe in your context you have brilliant people who can write testable code without doing TDD, but I haven’t seen that yet durig the last 12 years. When a system grows the added complexity makes writing tests after a huge burden when the design does not support it.

I can’t provide you with fool-proof evidence, but in my experience, TAD has always lead to lower quality in both the system under construction and the tests. Googling for this subject finds a lot of texts that support my view.

I must disagree, I’m afraid, with you comment, “Writing tests after also leads to tests that are difficult to maintain and brittle as the your code was not designed to be testable.”

Firstly, of course we write our code to be testable, even when practicing TAD. It’s not that we forget that we will need to test it afterwards – that, “Afterwards,” is typically 3-4 hours later.

People were writing testable code long before TDD was invented.

Also, I’ve not seen any evidence that TAD leads to tests that are difficult to maintain; can you provide a reference?

Thanks,

Shmoo.

from a practical point of view, specific things of the ongoing developments need to be transparent (visible, observable, inspectable), in the first plane for those responsible of the outcome, the ones that do the actual work.
not for others.
still is a great thing that a team can tell to customers, managers or everyone else: “we feel confident, we can be open and you can look and get a sense of what is really going anytime”.

On the other end when people not responsible of the outcome and not involved in the work *demand* for transparency, the transparency in my opinion should be *reciprocal*.

for example when the observation provoke in the external observer some feedback (doubts, concerns or satisfaction), it must be shared early and with all the team members together (ideally at the retrospective).

another example is when an external observer have a meeting about topics that affect or involve the team work or the project, at that meetings should in the first place attend the whole team.
when this is not the case, the outcome of the meeting should be shared early with the whole team, with the same reciprocal transparency that is demanded to the team.

I think that one should be able to ask only for as much transparency is ready to reciprocate. this is the same between team members and people outside the team.
And I think from a practical point of view that when this is not the case, transparency does not work well for the project and this enable other dysfunctional behaviors.

I used mscgen today at work and liked it a lot. I used to draw diagrams by hand using dia, but this way is just so much better. Updating the source file is just so very, very easy. No more fiddling w/the mouse, just type and generate.

Another tool I wouldn’t want to live w/o, by the way, is the timeline.

Coming back to the subject itself, I believe that part of the distrust is just fear of the unknown. I can tell this by the way I feel about things in project. I almost always worry least about the components that I’m working on and the other parts worry me. So it’s just not lack of trust, per se, it is also the fear of the unknown. So adding visibility some way could help the other parties you work w/ and that can be a valuable thing. If you can, just by drawing a few boxes, make others feel more secure, isn’t it worth it?

I think it is. And I took way too long in our current project to do it. I kind of think that removing the fears of others is part of taking care of the team.

But still, I know what you’re talking about and don’t disagree.

thanks for the comment!

you can write unit tests after development and before production but then you will miss the biggest effect TDD has. Testability. With TDD you write your code to be testable. Writing tests after also leads to tests that are difficult to maintain and brittle as the your code was not designed to be testable.

There are plenty of writings about TDD versus TAD in the Internet and I suggest that you lookup a few articles. In my opinion TDD’s benefits are indisputable.

Excellent post. Very concise.

You write that, “It is certain that no-one will write comprehensive unit tests after the code has been put to production.”

That may or may not be true, and forgive me if I’m misinterpreting you, but you seem to be offering two choices: TDD or writing unit tests after production.

Can’t we write unit tests after the code but before production?

Kind regards,

Shmoo

We try to gather some historic data so that we could give reasonable estimates when those questions arise.