Mike Kaufman
Posts: 125
Nickname: mkaufman
Registered: Jan, 2007
|
|
Re: Testivus - Testing For The Rest Of Us
|
Posted: Feb 9, 2007 7:35 PM
|
|
Re: "Developer testing" and "Developers should take responsibility for testing (all of) their own code".
In practice I strongly agree that a developer should be producing tests for the code they write. But in terms of defining things I think it is far more useful to focus on the nature of the tests, independently of who is responsible for writing/maintaining them or how the writing of them fits into the development process.
I'm far more interested in what types of tests are most useful for particular situations, what their strengths and weaknesses are, techniques etc, as opposed to who should write and maintain each test. I see that as a quite separate and largely orthogonal issue - especially because organizational structures, job titles and roles all tend to vary anyway. If you mix the two together, there's even more scope for argument and misunderstanding. If, instead, the purpose and nature of various sets of tests are well defined, it's usually pretty obvious who should be doing what (or at least that can be debated in its own right).
I guess this all stems from a personal viewpoint that sees the tests themselves (of all kinds) as a part of the "product", rather than as part of the development "process".
In the same vein, whilst I agree with Alberto's earlier point that "unit test" isn't a useful name for anything, because it's too vague and is taken as meaning different (often very specific) things to different people, I don't personally like the term "developer testing" either. It doesn't say anything to me about the nature of the tests, just who should be doing them. That lets you regard almost any type of test as a "developer" test or not, depending on your idea of the "developer" role. It all seems a bit circular - "developer test" tells me that the developers do it, then I'll regard whatever tests the developers are actually doing as "developer tests" and any tests that they aren't doing as not being "developer tests". And what if your ogranization (rightly or wrongly) has dedicated test-writing programmers sat alongside dedicated code-writing programmers? Are these then "developer tests" with no actual "developers", or are they "tester tests"? :-)
I suspect there will also be people that read "developer tests" as implying that the tests are owned by the developers and private to them (e.g. the developers use these tests themselves, but then throw the finished code "over the fence", without these tests, for other people to do their own tests on it).
So I think what Alberto is calling a "developer test" I'd probably want to call a "detailed test" or a "code test" or something like that. Unless I've misundertood what he means by "developer test" - I might just be reading that to mean what I want it to. Or unless the "no dogma" really means we're just trying to encourage people to do tests, any tests, please, pretty please (in which case calling it all "developer tests" seems ideal, but I suspect you can't go anywhere with it).
Actually, in private I still tend to refer to almost anything that tests the behaviour of specific pieces of code as a "unit test", just for lack of anything more descriptive that rolls off the tongue as easily. From here on I might try to re-train myself to call them "code tests", as I think that better reflects what I'm doing and should at least make people ask rather than assume.
|
|
Previous Topic
