You've been kicked (a good thing) - Trackback from DotNetKicks.com

>>>Any test is better than none, despite what many in the business will tell you.  I'd take 10 badly written "unit tests" (that zealots are quick to point out are really integration tests) rather than one well-written one. <<<

I was with you until this point.

1 well written test has business value, 10 badly written tests further concrete a poor design, making your code more and more rigid over time - eliminating rigidity should be one of the core principles that drives your coding standards, adding tests should not.

Here are the badly written tests for your code, I just made a manager smile by adding dozens of new, passing, unit tests ... I just made my other developers weep openly in the office at an appaling set of tests, all of which are valid by your criteria, and all of which pass.

Refactoring according to the "bug" you pointed out in this is now a case of rewriting 22 unit tests none of which added no value to the application, and even after rewriting will still add no value.

public Address GetBillToAddress()

{   return shippingAddress;  }

Address myAddress = new Address();

myAddress.ShippingAddress = "my address";

Assert.Equal(myAddress.ShippingAddress, myAddress.GetBillToAddress());

Assert.Equal(myAddress.GetBillToAddress(), myAddress.ShippingAddress);

Assert.Equal(myAddress.GetShippingAddress(), myAddress.GetBillToAddress());

Assert.Equal(myAddress.GetBillToAddress(), myAddress.GetShippingAddress());

Assert.Equal(myAddress.GetShippingAddress(), myAddress.BillToAddress);

Assert.Equal(myAddress.BillToAddress, myAddress.GetShippingAddress());

Assert.Equal(myAddress.ShippingAddress, myAddress.BillToAddress);

Assert.Equal(myAddress.BillToAddress, myAddress.ShippingAddress);

Assert.NotNull(myAddress.GetShippingAddress());

Assert.NotNull(myAddress.ShippingAddress);

Assert.NotNull(myAddress.GetBillToAddress());

Assert.NotNull(myAddress.BillToAddress);

Assert.True(myAddress.GetShippingAddress().Length>0);

Assert.True(myAddress.ShippingAddress.Length>0);

Assert.True(myAddress.GetBillToAddress().Length>0);

Assert.True(myAddress.BillToAddress.Length>0);

Assert.Equal("my address",myAddress.GetShippingAddress());

Assert.Equal("my address",myAddress.ShippingAddress);

Assert.Equal("my address",myAddress.GetBillToAddress());

Assert.Equal("my address",myAddress.BillToAddress);

And ... because condensing this to one comment would have been messy ...

One of the primary functions of a test is to document intent. Probably a more important objective than to verify correctness.

A badly written test will concrete the bad design not only into the code base, but also into the intended usage patterns, and into the common language that is shared within the project and team - it will cause so much fall out across the project, that I would suggest that zero tests is better than a single poorly considered test. Udi got it spot on this morning, tests are not things which have TestFixture on them, they are well considered, well designed and have business value *in themselves*

Having been on a projkect which had nearly 6000 unit tests, which had been written poorly and to meet management expectations that numbers of tests would rise in line with progress (or vice versa), I can assure you it is not a position you want to be in. That codebase may have had some very valuable tests, but as 30% of them failed and were ignored every day as they were the result of refactoring or later changes, the whole lot had to be dumped to ensure that progress could continue without spending the whole development team's time on rewriting tests non stop.

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #191

@Casey

The trouble is that your argument becomes 'let's not do unit tests because they are too hard'  very quickly. It is great to teach people what the best practices are, but its hard to get folks to run better when they don't even know how to crawl.

Most of the people I know who now speak about best practices in unit testing learnt the hard way, by getting it wrong. A few folks got lucky and had someone on site to help them out who had that experience, but most of us did not. How did you start Casey? Did you learn by making mistakes? Or have your tests always been perfect, never needing refactoring.

It is arrogant to assume that people do not write good unit tests because they cannot grasp the value of those best practices. People do need though it is to practice in order to acquire new skills. You cannot learn the advanced techniques without learning the basics. Years ago when I used to do fencing at school I spent the first few lessons mastering footwork, without even holding a sword. In a fight a lack of a sword would be useless, but you had to master the basics first. The same is true of TDD, people need to master the basics.

For most of us that learning has always occured on the job. To deny that is to suggest that you have never written a system where you looked back and though I could have done better.

Indeed the purpose of the retrospective is to allow us to improve what we have just done.

I'm not ashamed to say that we have to go back and revisit our code in later iterations to clean up debt that we did not spot in the first iteration, because that is the common experience. As we write more tests, as we experiment with new techniques we learn more. When mocks came out we followed a lot of 'best practice' and mocked our dependencies. That caused us pain so we changed our practice. We don't know that beforehand, we had to learn it. And it was not the common wisdom of the day.

We need to spread the understanding that we all had to learn the basics and then improve. A lot of people give up because they think that the targets we set are beyond them.  They imagine that wisdom bursts forth full formed like Athena from Zeus's head. It does not. It comes with experience. They do not realise that we are able to give the advice we give today, because we learnt from experience.

I don't think that Tim is saying he wants bad unit tests in the pejorative sense that your comments allude to i.e. write the worst tests that you can. I think he means in the sense that it is better that folks begin the learning experience instead of giving up because the 'barrier to entry is too high'.

We are in danger of turning TDD into series 7 of Lost. So esoteric that no one who has not been with us from the beginning can start watching. We need to tell folks to start at Season 1 and work their way through.

Their advantage is that they can get to where we are a lot faster by learning from our answers to the problems they hit.

But the journey of a thousand miles always begins with the first step.

@Ian

There is no business value to the tests I gave, and yet I have seen exactly those tests time and time again on codebases, where the managers proudly tell me they have a really tight ship. A small refactoring excercise becomes a nightmare in test maintenance.

If a developer doesn't know how to write a good test (not the same as how to use SOLID or how to test only a unit), then whatever they produce will be bad - and they really should not be putting it into the code base.

I started by writing unit tests, trying it, but *not* writing tests for the sake of it. I started by writing tests where the logic I was writing was too complex to verify by observation only.

In fact the first unit tests I wrote were against a calculation engine to measure and calculate yardage of rail tracks. One class and one class only in that project had unit tests, and they tested only what the requirements said they should verify as expected behaviour of test data in vs results out.

I could have written a few thousand tests against that codebase very easily, and very quickly, and given managers the impression these had value and that I was working hard - I would have been lying.

Bad tests are worse than no tests - this is not a debate about how to do TDD or POUT or what a "unit" is ... this is what happens if people who do not understand what a "test" is start writing "tests" in their tool of choice ...

Our current project has around 180 unit tests, it probably *should* have 2000+ but I'm the only developer on it confident enough writing unit tests to do them - for the others I'm not enforcing writing tests on them, I am enorcing writing good code in the first place that we can refactor easily afterwards, and evolve the tests around that when that code becomes more stable.

This whole &quot; lets make TDD easier for the masses &quot; thing is getting out of hand . Unit tests

@Casey

Why are you the only developer writing tests? Why are you the only one who has that confidence. The fact that you only have 180 out of a projected 2000 tests suggests that you have a big problem. That problem might be bigger than the problem of some tests that have no value.

I hear you on people just 'doing the numbers on testing' but again I don't think that is what Tim is saying.

This whole &quot; lets make TDD easier for the masses &quot; thing is getting out of hand . Unit tests

Tim's approach leads to the tests I gave above - because the developer doesn't know where to stop, or what tests are adding value and which aren't, or which are causing rigidity, and which are testing implementation not behaviour.

I'm the one writing tests as we are testing the core, business value is derived by delivery, not by training developers on this project. Technical debt is acceptable.

@Casey I honestly don't think that Tim is proposing the tests that you outline in your example.

I think he is proposing not worrying too much about Micheal Feathers rules of good unit tests i.e. he may have integration tests etc.

I think you are taking a specific issue that you have and assuming that Tim is proposing that. Which he is not.

Without tests btw you cannot refactor the rest of your code base. Refactoring always implies tests to preserve behavior, even bad tests. You can change your code, but without tests your risk is unbounded.

I propose learning first ... on that point we differ - I don't want anyone learning in a production code base ... they can learn on their own time, in training sessions, on spike code, or anywhere else, except production code.

Anyone left unguided will write the example unit tests I gave you based on your example ... I didn't need to use SRP or any other principle to screw that up ... how do you propose stopping people writing those tests?

Add a tool that means you don't even have to write good code to add a bad test on top and you will end up with shockingly bad codebases - managers will still only look at numbers like # of tests and coverage % - so your job is safe though.

@Tim

>>>Often we hear about the 5:01 developer.  Where else are they going to learn if not on a production codebase?<<<

train them, or fire them - simple solution. Don't let them start learning on production code, or make sure you only ever work in pairs.

Pingback from  Dew Drop &ndash; October 1, 2008 | Alvin Ashcraft's Morning Dew

>>>Kind of like NFL quarterbacks...they may be great in practice but they need experience and game-time to really mature.<<<

But they didn't get to the NFL without playing at high school, then at university, then in the reserves ...  

Pingback from  2008 October 02 - Links for today &laquo; My (almost) Daily Links

I think I'll have to agree with Casey on this one. On the original subject I mean, not on the whole "where to learn" issue.

The problem with having developers just start writing tests out of nothing, tests that will not add real value, is that they will not see the advantages the tests could have had.

A test has advantages when it either saves time and / or prevents bugs in production.

If a developers experience with tests is that they only slow him down (writing and maintaining the test) and that the test has never given him any tangible benefit, he will not, at least not by himself, start designing with testability in mind, or start writing tests again, the next project he is on.

Now that's a long sentence. Sorry about that. ;)

Anyway, I doubt the intended goal, which is getting the develop into TDD, will be achieved if his first experience with it is negative, because of poor guidance or the lack of a clear goal and vision.

Pingback from  Arjan`s World    &raquo; LINKBLOG for October 2, 2008

There has been a fair amount of activity in the blogsphere to Roy&#39;s original post about increasing

There has been a fair amount of activity in the blogsphere to Roy&#39;s original post about increasing

There has been a fair amount of activity in the blogsphere to Roy&#39;s original post about increasing

Buspar online med.