The Artima Developer Community
Sponsored Link

Weblogs Forum
Testivus - Testing For The Rest Of Us

51 replies on 4 pages. Most recent reply: Jul 25, 2007 2:43 PM by Ashwath Akirekadu

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 51 replies on 4 pages [ « | 1 2 3 4 ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Testivus - Testing For The Rest Of Us Posted: Feb 9, 2007 2:27 PM
Reply to this message Reply
Advertisement
> Perhaps the only dogma is that "developers should take
> responsibility for testing their own code."
>
> Thoughts?

Make it "all of their own code" and I think that's right. And really isn't that the goal? Helping to make this a reality for more (all?) developers.

Mike Kaufman

Posts: 125
Nickname: mkaufman
Registered: Jan, 2007

Re: Testivus - Testing For The Rest Of Us Posted: Feb 9, 2007 7:35 PM
Reply to this message Reply
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.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Testivus - Testing For The Rest Of Us Posted: Feb 12, 2007 6:34 AM
Reply to this message Reply
> > See this is the kind of thing that unit tests are
> terrible
> > for. I would do something like create a tab delimited
> > file that contains values and their squares. In
> addition
> > you can have a random tester.
>
> I would rephrase this: it's not something that unit tests
> are terrible for, it's something that data-driven tests
> are perfect for.
>
> And data-driven tests can be either unit or functional
> tests (see @DataProvider at http://testng.org).

It's a marginal improvement but doesn't come close to the kind of thing that I am looking for.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Testivus - Testing For The Rest Of Us Posted: Feb 12, 2007 8:59 AM
Reply to this message Reply
> > > See this is the kind of thing that unit tests are
> > terrible
> > > for. I would do something like create a tab
> delimited
> > > file that contains values and their squares. In
> > addition
> > > you can have a random tester.
> >
> > I would rephrase this: it's not something that unit
> tests
> > are terrible for, it's something that data-driven tests
> > are perfect for.
> >
> > And data-driven tests can be either unit or functional
> > tests (see @DataProvider at http://testng.org).
>
> It's a marginal improvement but doesn't come close to the
> kind of thing that I am looking for.

Can you expand on what you are looking for?

--
Cedric
http://testng.org

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Testivus - Testing For The Rest Of Us Posted: Feb 12, 2007 9:39 AM
Reply to this message Reply
> Can you expand on what you are looking for?

I've mentioned what I've hacked out over the course of this thread but here's what I want:

A execute a test script with canned input/data and capture any number of document outputs (e.g. 1000 200KB XML files) and write them to a directory with an identity filename.

Compare these files to a set of existing documents. Report only changes and missing documents. Provide simple configuration for evaluating correctness of non-static data (like timestamps.)

Build a report of the results.

Do this for any number of tests autonomously. Include ability to promote results to test data.

From what I see in @DataProvider, it works for simple data and outputs but doesn't really scale up to what I am looking for and have done in the past.

John Calcote

Posts: 3
Nickname: jcalcote
Registered: Mar, 2005

Re: Testivus - Testing For The Rest Of Us Posted: Feb 20, 2007 10:33 AM
Reply to this message Reply
Testivus. Bravo! I love the IDEA of test-driven development, but I find it very difficult to implement TDD in the sort of applications that I write - server software that generally run as daemons or services. I've found the best way to add "unit tests" so this sort of code is to compile separate little applications from individual source files that contain a test-main in #ifdefs - and Unix/Linux autotools support this sort of testing, as well.

Ashwath Akirekadu

Posts: 3
Nickname: akirekadu
Registered: Sep, 2006

Re: Testivus - Testing For The Rest Of Us Posted: Jul 25, 2007 2:43 PM
Reply to this message Reply
Love this post!! And of course, "The Way of Testivus" article is very entertaining and very useful.

Flat View: This topic has 51 replies on 4 pages [ « | 1  2  3  4 ]
Topic: Testivus - Testing For The Rest Of Us Previous Topic   Next Topic Topic: What Will the iPhone Mean for Mobile Development?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use