Kill the TDD crowd
Yes, I realise I’ve mocked and taunted all these test driven zealots before. However, I am filled with an almighty rage right now following a rather heated discussion on IRC. So, thanks to crazybob, Jon Tirsen (for a very very stupid comment on crazybob’s blog), Dan North, and Anthony Eden for the discussion.
The problem with the TDD crowd is that they’re unwelcome guests in a world that doesn’t want or care about them. I’m very sick of TDD bigots being snooty, getting offended, and angrily tugging at their unmentionables every time they see a unit test that doesn’t meet their ludicrous standards for what constitutes a unit test.
What troubles me about this is how incredibly narrow sighted it is. Sure, you end up testing some part of the container too. Welcome to the distinction between a unit test error and a unit test failure. It’s trivial to ensure that when the container messes up, it’s very clearly and easy to spot. Not to mention that in the real, sane, sensible world, it’s not exactly heretical to assume that your servlet container does what it says on the tin and can actually manage to run servlets.
Hell, if you don’t like servlet containers, Why not distrust the JVM too? Write your unit tests to not require a JVM! Hm, OS’s have also been known to flake out, so try to avoid those when writing unit tests. Avoid anything mechanical and electrical either, while you’re at it. They’re all containers or external resources that you must not depend on or assume are present!
I do understand what the TDD folks preach; they want their design and functionality to be defined in terms of tests. I wish they’d make it clear that this has NOTHING to do with unit testing. The fact that they use junit to do their filthy work is an abuse of junit, and does nothing but piss everyone else off when those jizzgobblers hand out their wisdom down to us mere mortals who are foolish enough to think that unit tests are…unit tests.
What’s amazing is that these same people will feel no shame whatsoever at using mocks. Forgetting that now you’re running in yet another type of container. Worse, you’re running in a container that has its own quirks and is often quite divorced from reality or how your actual code will run. So not only are you now testing the mock library (and the ones I’ve tried have all been surprisingly rubbish, you spend most of your time writing setup code), but you’re also testing a library that will not benefit you in the slightest when it comes to real usage!
I don’t write my tests first. I know very few people who do. It’s awkward, fragile and unintuitive. For those who enjoy it and find that it’s none of those things, great! At best, I’ll do a mixture of the two, and have something vaguely functional, then write a testcase and make sure it tests all the conditions I’d like it to pass under even though I know that it’ll fail.
Of course, I’m sure that the TDD crowd will now get all indignant, and pontificate about how I just don’t ‘get it’. Swine!
January 16th, 2004 at 12:33 pm
Who you calling a jizzgobbler?
January 16th, 2004 at 1:36 pm
What’s the purpose of tests – to figure out when things don’t work. The more you stub (your toes) and mock (your peers) the more certain you can be that your code is failing and not someone else’s. Problem is – the most important thing is to know that something doesn’t work – not that it’s your stuff doesn’t work.
If someone else breaks their contract – and therefore your code – do you want to know when you regress your unit tests – or do you want to figure it out sometime later – perhaps much later. The more you rely on stubs/mocks the less chance you have of finding bugs. Write your tests to depend on the libraries/systems/code they depend on – as long they are somewhat stable. If you can’t rely on them because they are unstable – then go ahead and gobble the mock cock.
January 16th, 2004 at 2:07 pm
Hani, you just don’t ‘get it’.
January 16th, 2004 at 2:12 pm
Hani,
there are more than one ways to test your code, unit testing, integration testing, acceptance testing, etc. …
each serves a different purpose. and if you want to test your code with a present of a container, that’s perfectly fine, it’s what categorized as an integration testing
there are many tools/framework to ease your effort, like the Cactus framework, JWebUnit, etc
so I am sure you could pick from any of the testing strategy to give you more confident of your code, and also make sure people don’t break the code that you have done, assuming you work with others
January 16th, 2004 at 2:24 pm
People using TDD looks beatiful & healthy.
TDD prolongates your lifespan.
January 16th, 2004 at 2:54 pm
TDD is good for mock enlargement.
January 16th, 2004 at 3:16 pm
I would not think testing the container is bad idea, once you deploy your app you have to live in a container anyway… so if it has quirks you’re better off knowing about it beforehand. Not on the day when you need to port your application from your mock container to a real one.
January 16th, 2004 at 3:35 pm
You’re are just doing some nice rethoric.
Say test Servlet with container is bad and without container is bad. So everything is bad…
You was totally right on IDEA and many things before. You miss this time.
January 16th, 2004 at 3:49 pm
Nice bile Hani, my response is here;
http://www.eaves.org/blog-archive/000020.html
Cheers,
— jon
January 16th, 2004 at 3:55 pm
I’m all for testing; but it does get infuriating when I spend chunks of time debugging the *test harness* code, not the *real* code. And the Mocks just seem to compound the problem…. Maybe I just need to spend more refactoring my test harness code; but then I would need to test my tests to make sure my test refactoring didn’t break the test harness….
January 16th, 2004 at 4:22 pm
assertTrue(isFirstPost());
January 16th, 2004 at 8:05 pm
All things should be done in balance. Was the app a very simple one? If so TDDing it with tests against the servlet object is just fine. But any complicated application is going the way of VB hell if you start putting your bussiness logic all in the get method of your servlet.
January 16th, 2004 at 8:21 pm
it seems that the response to tdd envolves just as many monkeys tugging their knickers (there, i said it). here’s the problem with having to test a servlet using servlet container: it’s a pain in the ass (hani, you know what i mean). forget about unit test integrity, or definitions or tdd purity, it means an extra 5 – 60 seconds (depending on the container and the size of your application because you wouldn’t want to use a “mock” web.xml) every time you want to run the damn thing. then, how do you test it? use httpunit? so how do you check the that the session got populated correctly? use cactus… argh, foul jakarta project!! do it manually? leave it to the QA department? i honestly don’t give a rat’s ass about the elegance of the principle, if removing depencies means that i don’t have to: start the container, make sure the database contains the just the right values, deploy all the ejb’s in the project if i just want to check that a servlet is returning some html (especially if i’m going to have to do it repeatedly) then isolating it is often the most efficient way of doing it.
as an aside, this is possibly the worst piece of reductio ad absurdum i’ve ever seen: “Hell, if you don’t like servlet containers, Why not distrust the JVM too? Write your unit tests to not require a JVM”. wtf???
January 16th, 2004 at 8:47 pm
hmmm… a link to crazy bob’s entry would have been useful… turns out he is creating a simulcrum of the real servlet container he’s going to run it in by using jetty (careful not to call is a mock container)… i take all of it back (well, except for the bit about the horrific don’t use the jvm rant). here’s the link for the rest of you: http://crazybob.org/roller/page/crazybob/20040115#unit_testing_a_servlet
January 16th, 2004 at 9:33 pm
Why use a container? I did a little digging when I wanted to test a JSP custom tag and needed the ServletContext and some other stuff.
http://sourceforge.net/forum/forum.php?thread_id=976750&forum_id=121751
Turns out StrutsTestCase has a much evolved version of servletunit, which is an abandoned sourceforge project.
Perhaps their mocks will provide what you need.
January 17th, 2004 at 3:30 am
Saying that using it for TDD is a misuse of JUnit is rather strange – as you probably know, one of the two authors of JUnit, Kent Beck, is actually *the* TDD proponent, and much of JUnit itself is written test-first, if I remember correctly.
January 17th, 2004 at 11:44 am
way to go Hani. I am sick of the TDD people too. I am not sick that they want to do TDD, but the way they preach and frown at the rest of us if we don’t follow. Fuck you TDD freaks, some people aren’t cult followers. Just go and jerk off in eachother’s presence, getting turned on by eachothers’ TDD loyalty and leave the rest of us alone.
January 17th, 2004 at 5:14 pm
Ryan, http://httpunit.sourceforge.net/doc/servletunit-intro.html
Its included in HttpUnit, no idea if they are maintaining it or about the abandoned part.
TDD works for me (mainly I’m more focused and productive). However, I too, have found that it does not work for other people. And I really could care less: its tested code that I care about not when the tests were written.
There really should be a distinction between TDD and Automated Testing (too bad the serverside is muddying the distinction in its current “TDD” series). I think some comments here lecturing on proper testing are only emphasizing that the distinction is unfortunately blurring.
Renaming TDD seems to be the best course of action. EDD: Executable Driven Development.
January 18th, 2004 at 7:50 pm
There are people dogmatic about everything even TDD. I dig TDD. Not sure if what I do would classify as pure TDD or not. Don’t care.
I do consulting and training. I don’t get to pick the process that companies do. I try to be pragmatic, and leave things a little better than when I got there. I am not out to change the world.
I prefer to use TDD. It helps me. To me testing is not a waste of time. I like quality software.
If I had a client, that did not want me to do TDD. I would be a closet TDDer.
I offer a Struts course. There are two versions of the course. One uses TDD for the labs. The students write the test, then they write the code (using StrutsTestCase and jWebUnit). The other version of the course does not use TDD.
Guess which one goes faster?
The average speed is about the same. It takes the classes about the same amount of time to finish the labs.
But, the non-TDD class has a much higher standard deviation. Why? I think it because they are not writting tests, and when something goes wrong, i.e., they missed a step or something, It is harder to find.
This is not scientific.
I read a study once that TDD saves time. I believe it. Maybe not for simple projects. But for real world projects.
It has been my experience that TDD saves time. I am not a purist, bigot, or advocate. Do what you want? I prefer TDD.
January 18th, 2004 at 11:56 pm
TDD has its point…but when it mutates into ClunkUnit and other *Unit tests, then it’s really, really annoying. Me? I typically use it on my domain/tech-specifics-free stuff. (the stuff that’s naturally POJO/conceptual). If your “core” is right, then that’s good enough. I mean, seriously, if servlets are just a caller/view on your “program”, why the hell do we need to test every little doGet/doPost/service method? A servlet is just a servlet (so I agree?). (maybe if it does some logic, then testing it (maybe if a parameter like “action=test” is used or some easy thing written yourself can be done), then you can maybe test what it does….but I’d expect that to happen only if it were very complex / drastic / seemingly bugprone. (which it shouldn’t be…if its just handling simple web stuff), To me, the most important thing is timing on servlets so I typically just time them with a simple call to Date. Doing fancy stuff for stuff that shouldn’t matter a whole (view and dispatch type logic) lot seems rather useless. Testing everything in sight is useless…might as well unit test the stapler, scissors and color copier too. Some people just like the mental masturbation of testing, testing and testing, ahhhh, their units all day…
January 19th, 2004 at 2:53 am
TDD is not about unit tests. If it makes you feel better, call it DDD (Defect Driven Development/Design) – features are specified via tests (unit or whatever), and you start off with a totally defective empty class, and gradually fix all of the defects that you care about.
A debate about whether to mock or not is not a debate about TDD – it is a debate about testing strategies. IMO, mocks are massively overused, but they do have their place. If you are yet to be convinced, try working on a 100 person project, over 4 years, with a mixed ability team, where the build takes over an hour, and then argue that using mocks wouldn’t make your life better by speeding up the build, removing servlet containers etc.
And in response to the post above about testing code in a real container before deploying… Only a retard would do that, unit tests are not about testing code in a production environment. That’s what integration tests, QA teams, staging and release testing are for.
January 19th, 2004 at 3:41 am
“I wish they’d make it clear that this has NOTHING to do with unit testing.”
How much clearer can I make it than this?
http://www.sys-con.com/story/?storyid=37795&DE=1
Cheers,
Dan
ps. TDD is nothing to do with testing.
January 19th, 2004 at 5:16 am
ApplicationX – the Unit Tests succesful,
N months later,
Integration/QA Testing, last thing that happens, and everything goes wrong.
Course, we all expected that. There are bound to be problems, no-one writes perfect code. And therein lies your problem, It’s almost certainly he case that A.N. Developer says “Oh, all my unit tests pass, so it must be something wrong with ‘SomeRealLifeComponentThatIusedMocksFor’”.
Don’t think the client is gonna give a flying pig’s ass for whether your unit-tests pass. It just isn’t possible for us to develop code without reference to the real world context in which it’s going to be used.
January 19th, 2004 at 5:57 am
Chiara,
Don’t you think you’re inconvenient with these words of your dirty mouth? what a ridiculous behavior, girl.
January 19th, 2004 at 9:04 am
“I don’t write my tests first. I know very few people who do. It’s awkward, fragile and unintuitive.”
Suddenly the limitations of Hani’s experience being to become clear.
I’ve noticed Hani also doens’t seem to know anyone who can reuse code above a cut-and-paste level.
January 19th, 2004 at 10:52 am
So, here’s a radical thought. Perhaps, the reason you are whining about the testing stuff getting in your way is that you are not doing Test-Driven Design. So skip the blathering about testing and try to make a cogent argument against TDD instead of picking at the nits.
January 19th, 2004 at 12:10 pm
|
|Integration/QA Testing, last thing that happens,
|and everything goes wrong.
|
Who said that happens last?
Integration testing, perf testing, load testing should be carried out throughout the project. Unit testing is just one of the types of testing.
However, (as mentioned above) dont ignore the last ‘D’ in TDD – it stands for DESIGN.
TDD is about letting your requirements, expressed as tests, drive your design – rather than some abstract, probably-wrong, “design” you have pulled out of your (e.g.) UML Hat.
-Nick
January 20th, 2004 at 10:01 pm
http://www.sys-con.com/story/?storyid=37795&DE=1
“NOTHING to do with unit testing.”
It may not be the focus but the primary means is to write the tests “first” or “client callers” (often called unit tests by most people I know) first. (then design some interface / then maybe implmenation second…(at least many will try to get the client to use nothing but interface types)
So what if we want to pontificate contrarily to seemingly transcend ourselves to escape everyone’s apparent and lowly misconceptions.
January 23rd, 2004 at 3:26 pm
Why does it hurt when I pee?
January 26th, 2004 at 11:27 pm
Unit tests are made under the assumption that Units are _good_. They seem to nearly always involve a rewrite of the code [if done a long time after the effect] and bludgeon the idea of privacy to death. Anyone know a good thesis on whether a Unit is a good thing or not?
Unit tests are great when you have defined example data, a pain in the arse when you spend more time on the test than the code.
TDD itself is also a pain in the arse. It’s bottom-up coding taken to the anal-degree. Testing each component before allowing it to take part in anything else. This is fine if you code from the bottom up, which means:
a) Lots of up-front design
b) Lots of mistakes
Personally I prefer top-down code. Create a scaffold of the front of the system and slowly fill in more parts of the behind. Stubbing methods out that have not yet been written with some hard-coded value. TDD fails to fit with this style of development.
January 27th, 2004 at 10:55 am
I can’t say I read blogs everyday, but when I do, all I see is negative hype. Why are you authors always negative and irritated and pissed off at the world? It seems your blood pressure must be constantly over the limit. Perhaps too much caffeine to boot. Take a chill pill and enjoy life. It’s not difficult to do.
February 1st, 2004 at 3:46 pm
I have learned a few things about TDD: First of all, it’s hard. It’s hard to find the very first thing to test, then it’s hard to write clean test code. And if you are not continuosly refactoring, you are not TDD’ing, just Unit Testing. Using mock objects is optimizing. If you agree with the rules of optimizing (don’t do it, do it last), you realize that mocks should not be introduced before they optimize something.
March 23rd, 2004 at 4:23 pm
I realize this is old, but I couldn’t resist this beautiful logic error, right here: “Hell, if you don’t like servlet containers, Why not distrust the JVM too?”
I keep containers out of my tests because I /do/ trust them, and not because I don’t. I trust them, so I don’t bother testing them. Don’t Test the Platform. It has the nice side effect of avoiding runtime environment complexity.
If you don’t like TDD, that’s fine. For the most part, we don’t care. Can’t we all just get along?