Are you doing test first anyway? Or in some cases you are doing some coding and then writing your tests to make sure code works? As for me I prefer to create a class. Sure, during class creation I think about its interface and how to test the class. But I dont write testing code first. Do you write it first? Do you think you should always write test code first?
views:
124answers:
3
+3
A:
Test-driven development, by definition, is writing your tests first. If you create your class first, the subsequent tests you write can be called Unit Tests, but it is not TDD.
There are many who say that writing your tests first improves code quality. I am inclined to agree, provided there is some effort put into the software design beyond just writing tests and making them pass.
If you are refactoring an existing legacy system, it is a good idea to wrap the functionality of that system in a suite of tests prior to refactoring. That way, you know if your code changes break something.
Robert Harvey
2009-08-09 04:44:16
Agreed, but do you see the sense in writing the test even before you can compile it? I`m not writing the whole class, before writing single unit test. I`m writing enough for test to compile and show me the red bar. Is there any sense to write unit test before it can even compile. But when you have enough code to compile unit test (not implementation but interface) you can do TDD.
Yaroslav Yakovlev
2009-08-09 04:51:49
It seems obvious to me that there needs to be enough code in the class under test for the test to compile. So yes, I agree with the notion of creating an empty shell class against which you can write your first tests.
Robert Harvey
2009-08-09 05:06:48
+6
A:
I'm not a purist in this matter (TDD involves more than just writing the tests first, it's also about initially writing very minimal, "hard coded" tests and refactoring them a lot -- see The Book by The Master himself).
I tend to test-first when I'm doing incremental development to add a feature to an existing module, and I insist on test-first when the incremental development I'm doing is to fix a bug (in the latter case I absolutely want a unit-test AND an integration-test that both reproduce the bug, before I fix the code that caused the bug).
I tend to be laxer when I'm doing "greenfield" development, especially if that's of an exploratory, "let's see what we can do here that's useful", nature -- which does happen, e.g. in data mining and the like -- you have a somewhat vague idea that there might be a useful signal buried in the data, some hypothesis about its possible nature and smart ways to [maybe] extract it -- the tests won't help until the exploration has progressed quite a bit.
And, once I start feeling happy with what I've got, and thus start writing tests, I don't necessarily have to redo the "exploratory" code from scratch (as I keep it clean and usable as I go, not too hard to do especially in Python, but also in R and other flexible languages).
Alex Martelli
2009-08-09 04:59:00
That seems like a very pragmatic, sensible way to approach things.
Robert Harvey
2009-08-09 05:05:04
Alex, can you please tell how you do the test first if you do not have the interface itself? Let`s say I need to test some ftp class that wraps ftp protocol and gives me a good interface to work with ftp. Sure I need to write tests first, but I always thought I need to write the stub of the class, like interface stub for this class and then write tests for it. Is that right? Or you are writing the tests even before you have any class stub? Just when you don`t have the class, how you do testing for it?
Yaroslav Yakovlev
2009-08-09 05:07:22
I mostly code in Python (plus, substantial C++, some Javascript, R, SQL, but, say I'm adding a new method: a test that tries to call that method (and fails because the method isn't there yet) is fine... except when I'm working in C++, when adding the method and an empty implementation first seems sensible (I guess you're assuming some static lang, right?)
Alex Martelli
2009-08-09 05:18:17
I`m assuming C#. I just think of TDD as way to make sure your assumptions on how everything is working are right and way to wirte a better code iteration by iteration. So it depends where you are starting. I just prefer to start with class and it`s empty interface or part of it. I can`t imagine how to start without class and any stubs for it and just write the tests first. What are these tests? I thought tests - the way to describe the required functionality in terms of your class and it`s interface.
Yaroslav Yakovlev
2009-08-09 05:32:45
A:
Lets be clear here, that TDD was designed for production code. If you want to follow the rules for TDD for production code, then the first thing you write is your first test.
I write my first test (before writing a line of production code), which may want to instantiate a new class and running it produces some sort of error, which I fix by writing the smallest amount of production code to get the test running.
If you want to do something else, then you can make up your own rules: You can write whatever code and/or tests you like to explore any designs or patterns or anything.
However, if you then want to write production code based on what you have learned from your experiments, you may well be better placed - but technically you should really throw away your experiments - to write your first test.
quamrana
2009-08-09 21:02:49
I have yet for someone to tell me why such a dogmatic approach is compelling.
Robert Harvey
2009-08-10 13:45:57
Its not so much dogmatism and discipline: The rules are there to reduce confusion as much as possible, to allow TDD to leave a trail of really good regression tests and to keep the design as simple as possible.
quamrana
2009-08-16 13:14:31