Course in Software Engineering

[woohoo]

So to answer.

The benefit of unit tests is that the next developer can come along, change some code - quickly run the unit tests and be confident nothing broke. Your kind of point and click validation of a change is much more error prone. You can then have environmental dependencies break you. We've all seen a dev say "but it worked on my box".

Your point about manual testing is valid though I would argue it's the best way to see if something actually works in practice. I could argue that you are relying on the unit test being up to date and well written. The "but it worked on my box" is another issue entirely.

And to your point on classes with one purpose not needing testing. You imply a class with multipurposes would need testing. The unit of encapsulation is the only thing that differs. In your world I would be testing at the package level. The one function classes are too granular to support meaningful testing. I would focus higher up, where they are aggregated into something useful.

My point was not clear if that is what you took from it. My point was that single purposes classes are easier to understand and was related to you point about unit testing being a way of describing how a class should be used. For me understanding code is difficult when it attempts to do multiple tasks and become messy and interdependent.

If you are working in a team with multiple developers constantly refactoring and improving things - unit tests are a must. Sometime you refactor huge bodies of code without having ever read it - good unit tests support that kind of thing. A number of times people have changed some code, the build has failed because of a unit test - and they go back and reexamine their change and go "oh yeah, didn't think of that". It saves everyone needing to be an expert on your stuff.

mmm that worries me a bit, if you change some code I believe you should know the implications and should test it - even before your testers get their hands on it. Obviously, if you are talking about changing huge bodies of code then you are working with some interesting code. When I have changed huge bodies of code it's usually due to a move from one tech to another - I would still be testing the outcome and not relying on unit tests.

However, I understand that from the sounds of it you and your team are doing well with TDD and good luck to you. Interesting points.

[woohoo]

And there's a strong argument that TDD (not 'unit testing'), where appropriate (which is most of the time) makes you faster anyway - so it's free.

This is an interesting one, "strong argument" - is there any real conclusive evidence that TDD improves developer/team/project performance?

[original PM]

This is an interesting one, "strong argument" - is there any real conclusive evidence that TDD improves developer/team/project performance?

Not really.


The biggest single factor which will improve any project is if the people engaged on it actually give a damn.

[browntractor]

However, I understand that from the sounds of it you and your team are doing well with TDD and good luck to you. Interesting points.

We don't do TDD. We use unit testing and a bit of regression testing. In my opinion TDD (as I described it) is a load of rubbish. It assumes that the problem space is completely understood at the start of the build - which it often isn't.

I write a few unit tests - usually at the end after I'm happy with the code, usually more if the code is tricky, less for simple stuff.

If you have an approach that works for you - good luck to you!

[browntractor]

Not really.


The biggest single factor which will improve any project is if the people engaged on it actually give a damn.

Agreed. Good, motivated people who work hard will usually deliver, barring political shenanigans derailing a project.

[SpontaneousOrder]

This is an interesting one, "strong argument" - is there any real conclusive evidence that TDD improves developer/team/project performance?

I suppose that these things are very hard to measure because there are to many variables. But anecdotal evidence from the big names & players who promote the idea would suggest so.

But for me personally it makes perfect sense.

I'm baking quality in from the start in the form of self-testing code - that is to say that the act of writing tests in order to direct my coding means that my code is testable by default, and already (unit) tested by the time it's complete.

Also by the fact that i've test driven my code there should be no more code than is absolutely necessary to meet the ends of the component being written. That code should be, if i did it right, close to as simple as possible in order to achieve those ends. So we have a nice 'lean' element at that low level.

The design should, more often than not, be better than if I'd thought it all up at the start - because it has emerged endogenously from the TDD process as a bespoke implementation to meet the specifications we're writing in the form of tests, rather than being built up front and then bent to meet those requirements that don't fit perfectly.

Refactoring is much more trivial because I can be reasonably confident that every line of code has a corresponding test which will fail if I change the semantics which that line of code expresses. Test-first, instead of TDD, can't get you that assurance. Changes don't need further consideration and testing with regards to the existing code as a 100% green test run means, by definition, that that everything is (more than likely) doing what it's supposed to do - obviously there's a point of diminishing return when it comes to testing variations of the same scenario.

I get short - fast feedback loops around my API decisions. When its clumsy I get that feedback very early on compared to building it all up front and then discovering that it doesn't feel right.

TDD helps me figure out what a solution should look like in the first place. If I don't have a clue what to do i can at least write a test to get me started.

TDD helps me keep specification and implementation separate. Designing a whole solution up front makes it very difficult to avoid inadvertently making assumptions about implementation detail when formulating APIs.




The list of pros is extensive, while the cost is minimal - having written a test I don't even then have to write the boiler-plate for the classes & methods. A few keyboard shortcuts and the IDE has implemented the skeleton for me from the test I wrote.

For that reason I think TDD, where it's appropriate, makes me a lot faster than without it.

[SpontaneousOrder]

When it doesn't work:

When TDD doesn't work. | 8th Light

[minestrone]

All this agile stuff is complete drivel, Kent Beck completely fooked up the first shot of it with Chrysler and went on to write a book on how great the system is which the industry has now taken on as a bible.

If the captain of the Titanic had survived and wrote a book on sailing big ships at night would anyone take it seriously?

Sheesh.

[SpontaneousOrder]

All this agile stuff is complete drivel, Kent Beck completely fooked up the first shot of it with Chrysler and went on to write a book on how great the system is which the industry has now taken on as a bible.

If the captain of the Titanic had survived and wrote a book on sailing big ships at night would anyone take it seriously?

Sheesh.

I don't think TDD is especially 'agile'. It's not like anyone ever followed the low-level designs under a waterfall paradigm anyway - as soon as you started coding you realised the design was broken.

[SpontaneousOrder]

All this agile stuff is complete drivel, Kent Beck completely fooked up the first shot of it with Chrysler and went on to write a book on how great the system is which the industry has now taken on as a bible.

If the captain of the Titanic had survived and wrote a book on sailing big ships at night would anyone take it seriously?

Sheesh.

Beck brought great success to C3 with what became XP. That's why everyne else started doing it.