Reply to: Course in Software Engineering

[minestrone]

I got 2 lines through it and couldn't be arsed reading the rest.

I'm away out for a pint.

[SpontaneousOrder]

Nobody ever did true waterfall, releases always got staged and functionality got added and bugs got fixed with each release but somehow agile has told us that never happened.

That still sound pretty waterfall to me. You just iterated through smaller ones.

but don't try and convince a forum of time served people in the computing industry that development was always waterfall until agile turned up.

You're making my own point for me then. What's 'agile' about TDD?

You have already made a tit out of yourself telling us that test driven development is not about testing, best get out that hole and stop digging.

Robert Martin says in 'Agile Software Development, Principles, Patterns, and Practices', this:

"The act of writing a unit test is more an act of design than of verification."

Moreover, by definition you can't test code you haven't written yet. So opting to write a test before writing any code implies that there is something beyond testing that is the driving factor behind TDD.

Calling me a tit for suggesting that TDD is not about testing is calling him a tit for the same reason.


Bob Martin is an enormously respected leader in the industry.

You, on the other hand, write things like this:

I very rarely ever write private methods and in fact I would have them banned, I cant see the point of splitting up a large public method into smaller private methods. It does make the readability of the code much worse as you have to use the IDE then to follow the code looking for calls rather than moving down one large method.

-- Minestrone

lol
Plus... doesn't understand self-documenting code.

If you can do that it is worse taking a 100 line method and splitting it into 10 10 line private methods gives you 110 lines of code and 11 methods, you have taken a clean interface with one method and turned it into a mess of 11 methods, to understand the code takes longer as code should be understood reading the interface not the code. You have leaked what was a less than ideal 100 line method but one that was encapsulated into poor API. Interface should always be king.

-- Minestrone

Doesn't understand what an interface is.
Supposes can understand 100 lines of code!!! from a public method interface?

Like Woohoo says:

Again, I hope I never have the opportunity to work with your code. Your a know it all and when confronted with a valid argument you insult, choose to ignore it or provide unrelated silly examples to confuse the issue.

Inheritance should be avoided at all costs.

-- Minestrone

tool.


http://forums.contractoruk.com/gener...ml#post1865695

[minestrone]

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.

Aye, the usual agile argument. everyone does waterfall.

I started writing software in the mid 90s and I can recall then major, minor and build numbering of releases back then.

Nobody ever did true waterfall, releases always got staged and functionality got added and bugs got fixed with each release but somehow agile has told us that never happened.

Agile is bulltulip on an industrial scale and it makes a lot of money for training companies selling stuff to non technologists but don't try and convince a forum of time served people in the computing industry that development was always waterfall until agile turned up.

You have already made a tit out of yourself telling us that test driven development is not about testing, best get out that hole and stop digging.

[minestrone]

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

The revisionism, my sides, my sides.

C3 got tulipcanned, it was a complete disaster, late and useless.

[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.

[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.

[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]

When it doesn't work:

When TDD doesn't work. | 8th Light

[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.

[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.

[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!

[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.

[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?

[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.

[SpontaneousOrder]

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".

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.

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.

If your app is static and only you change the code - I agree, unit tests have less value with regard to maintenance. They still have value as little client apps - so they force you to at least think about good APIs up front. And they serve as little bits of documentation.

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.