Course in Software Engineering

[SpontaneousOrder]

I don't think this is true, many of the programmers I come across rarely use TDD or don't use it 100% (or anywhere near that). I want to like TDD I really do, but I just don't think it's that necessary. I use the TDD tools occasionally as a test harness, though I often just write a test harness depending on what I'm doing. If I'm designing a complex bit of code I will just make a note of the steps as comments.

If I had to recommend TDD to a developer, I really could not convincingly say why they should take the effort. It's the same reason I stopped using full on ORM (EF etc) I could not explain adequately to a developer why they should use it.

Oh and software development is not engineering.

tdd is NOT about testing!

Plus...

I use the TDD tools occasionally as a test harness,

what the **** does that mean? 'TDD tools'?!

[browntractor]

I don't think this is true, many of the programmers I come across rarely use TDD or don't use it 100% (or anywhere near that). I want to like TDD I really do, but I just don't think it's that necessary. I use the TDD tools occasionally as a test harness, though I often just write a test harness depending on what I'm doing. If I'm designing a complex bit of code I will just make a note of the steps as comments.

If I had to recommend TDD to a developer, I really could not convincingly say why they should take the effort. It's the same reason I stopped using full on ORM (EF etc) I could not explain adequately to a developer why they should use it.

Oh and software development is not engineering.

Test focused development is a very good thing. It leads to higher quality code. Simplified: worse code is harder to test. Testable code is better. Therefore if you have been building in testability from the start, you more likely end up with better code.

Think of the next guy that will come along. They have to extend your stuff without knowing how it all works. This is where the unit tests come in handy. I can make my changes and quickly check that I haven't broken any of your stuff, by running your unit tests.

Like all things in software engineering, there is a trade off - between the cost of producing and maintaining the testing code...against future gains in productivity. This is where an experienced engineer applies his judgement. Not necessarily more tests , but better quality, meaningful, tests.

[VectraMan]

tdd is NOT about testing! Sheesh.

What does the T stand for?

I think you've proved my point.

[SpontaneousOrder]

What does the T stand for?

I think you've proved my point.

That's like saying banana boat rides are all about bananas.

[SpontaneousOrder]

Just to clear up some confusion, TDD is a specific technique used by some developers whereby they start a piece of work by writing a bunch of tests. These tests are supposed to define the contract that the soon-to-be-written code will offer. These are not unit tests- they are more like automated functional tests. The tests all fail at first , because there is no code at the start. As the implementation progresses, the tests start to pass. Code is complete when all tests pass. That is TDD- starting the implementation with defining the set of tests that must pass for the agreed requirements to have been implemented.

This is much different to the common practice of writing bunches of unit tests as you write code- which as Minestrone points out - merely validates your implementation is working - it doesn't validate that you implemented the right thing. It is much lower level.

Although that sounds more like 'acceptance test driven development'.
But the principle is roughly the same - except with TDD you'd write only one test at a time, and make it pass by writing the most simple code possible to make it go green - even if it's hard coded.

It's about design. If TDD were about testing then we could just cary on writing our code and then writing tests to check it works as we've been doing for ages.

You also get nice side-effects which make it a no-brainer.

[woohoo]

tdd is NOT about testing!

Plus...

what the **** does that mean? 'TDD tools'?!

Why so angry in your comment? TDD tools for example I use resharper to run unit tests and use Moq t mock dependencies etc. As I said if I'm writing something more complex I spell out what the code does in comments before I write it or I will sit down and design the code.

[woohoo]

Test focused development is a very good thing. It leads to higher quality code. Simplified: worse code is harder to test. Testable code is better. Therefore if you have been building in testability from the start, you more likely end up with better code.

Think of the next guy that will come along. They have to extend your stuff without knowing how it all works. This is where the unit tests come in handy. I can make my changes and quickly check that I haven't broken any of your stuff, by running your unit tests.

Like all things in software engineering, there is a trade off - between the cost of producing and maintaining the testing code...against future gains in productivity. This is where an experienced engineer applies his judgement. Not necessarily more tests , but better quality, meaningful, tests.

So your first point is not qualified so I'm not going to argue against that. But the second point I would say that properly designed, named and well written code will describe itself and it's purpose. If something is complex or requires explanation then comment or explain it. You don't need to look at the unit tests to see how it works, just look at how the code has been used to see how it works.

[tractor]

...

Although that sounds more like 'acceptance test driven development'.
But the principle is roughly the same - except with TDD you'd write only one test at a time, and make it pass by writing the most simple code possible to make it go green - even if it's hard coded.

It's about design. If TDD were about testing then we could just cary on writing our code and then writing tests to check it works as we've been doing for ages.

You also get nice side-effects which make it a no-brainer.

I've been wondering how long it would take until someone brought up design. How long will it be before we visit the precursors to design and their relationship to success/quality?

Given TDD suggests starting with a single test, it would be nice to see an example.

There are many levels of software development/engineering. From Application to Component. Is TDD suitable for all aspects of development?

[browntractor]

You don't need to look at the unit tests to see how it works, just look at how the code has been used to see how it works.

That's exactly what you don't want to be doing. Strive to work at the highest level of abstraction that you usefully can. That way, you decouple yourself from details, and can move faster.

The unit tests can be done to document a contract of how the code *should* be used, not how it *is* being used.

[SpontaneousOrder]

That's exactly what you don't want to be doing. Strive to work at the highest level of abstraction that you usefully can. That way, you decouple yourself from details, and can move faster.

The unit tests can be done to document a contract of how the code *should* be used, not how it *is* being used.

Exactly - tests should describe the desired behaviour. The implementation is detail you don't necessarily care about.

@Test
public void AddFoo_FooIsSpecial_EventIsAudited() {

//setup a foo
//add foo to the unit under test
//verify that audit service mock was called with object matching foo

}


I can look through these tests and see what the system is supposed to do without even reading a single line of actual code.
If I want some more detail I can look at the test implementation and see that some audit interface should be invoked and consumes a foo object.
I probably don't need to actually look at production code at all.