• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

What Are Good Tests ?

 
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Andy and Dave,
Appreciate the sample chapters of your great books.
Your "Pramatic Unit Testing" book tells that, good tests are A TRIP - Automatic, Thorough, Repeatable, Independent, Professional tests.
Could you please elaborate on this A TRIP more? Thanks a lot.
 
Author
Posts: 55
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A-TRIP.
Good tests are automatic: no human intervention needed to run them, and you can run all of them at the touch of a button.
They are thorough in that they test everything they need to test (which does not mean 100% code coverage or even anything close to that).
Repeatable means that you'll get the same results every time; no test relies on anything that isn't under your direct control (like the time, currect stock prices, other entries in the database, etc.)
Independent means that tests can be run in any order, and that no test depends on any other test having run or not run. You want to be able to run individual tests in isolation (especially when tracking down a bug) without having to remember to run some set of tests first, or clean up after, etc. Tests should take care of themselves.
Finally, tests should be professional-- written with the same care and attention as production code. Refactor test code, make your own classes, methods, and so on that are JUST for the testing environment. Don't copy and paste and make crappy looking test code! It's expected that there will be at least as much test code as production code, so you want to make it easy to work with.
That's the message of the book, for more details, buy the book :-)
 
Doug Wang
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Andy Hunt:

That's the message of the book, for more details, buy the book :-)


Andy,
Thanks for the entertaning message. Now I am more eager to read the book.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ron Jeffries & Kent Beck & co often talk about tests express requirements and demonstrate how to use the class under test. If you value these things, it's important to name your test classes and methods well and provide realistic examples. And maybe even (gasp) comment a couple of em.
What's your take ... are these things part of goodness?
 
Andy Hunt
Author
Posts: 55
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Absolutely, and they are a natural outgrowth of practicing test-first design. If you start off with a realistic, commented test (and even just a dummy implementation that doesn't do much but return hard-coded strings), you've got a working, detailed spec. A spec that is active, and can track your progress as you implement the class for real.
Even if you don't strictly follow test-first design, it's still useful to have portions of your unit test act as examples and documentation for future developers (which may include you six months from now!).
However, you will also have unit tests that are there for your benefit to check weird conditions and boundaries that may not be as useful as examples to someone else. So you may find it helpful to comment the more example-oriented tests as such (e.g., /* SAMPLE USAGE: */).
[ February 19, 2004: Message edited by: Andy Hunt ]
 
Doug Wang
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mm, test-first design. My understanding is that, such tests (in TFD) focus on testing against the software spec. It intends to ensure that the developer are designing and coding on the right way. How can a developer do unit testing against the inner structure of a module which haven't implemented yet?
Anyone please corrects me here. Thanks.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Doug Wang:
How can a developer do unit testing against the inner structure of a module which haven't implemented yet?

Test-first development (or test-driven development, or test-driven design) is not about testing the internal structure. It's about declaring a piece of contract and then implementing it.
As a trivial example...
- Hmm, I have this Calculator class and a test case named CalculatorTest.
- It already knows how to sum up integers, but I also want it to be able to subtract integers; I'll write a test for it!
- Ok, the compiler complains about a missing "subtract" method in Calculator. I'll have to add it.

- Right. Now it compiles, but the test suite fails as expected. Good. Now I'll have to make the test pass.

- Yes, now the test passes. Now, what else do I want the Calculator to do...?
 
Andy Hunt
Author
Posts: 55
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Mm, test-first design. My understanding is that, such tests (in TFD) focus on testing against the software spec.


True, for some definition of "spec". If you've got a formal specification then yes, that's what the unit tests will test (this brings up an interesting possible violation of the DRY principle, however).


How can a developer do unit testing against the inner structure of a module which haven't implemented yet?


Not necessarily against the inner structure, but certainly against the interface and publically-accessible methods.
Test-first design is very useful when you don't have a spec and you're making the stuff up as you go. Show of hands, please: how many of you get handed iron-clad specs from which you write code, and how many of you have to "wing it" to some degree? (e-mail to andy@pragprog.com and I'll post a tally here).
Writing the tests for a class as part of the design activity for that class is hugely valuable. There are no internal structures to test, but you can define the public behavior of the class, determine boundary conditions, responsibilities, things you will support and things you decide not to support, and so on.


Anyone please corrects me here.


Alas, there are no absolutely correct answers... :-) Just varying shades of gray. Or is it grey?
 
author & internet detective
Posts: 41184
848
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Test-first design is very useful when you don't have a spec and you're making the stuff up as you go


Test first design is useful even if you have a detailed spec (rare as that is.) A spec can say things like "balance = total of activity" But test first design says what to do if the method is passed invalid data. This is useful to future developers (and you later.) A spec could never provide this level of programmer detail.
 
Doug Wang
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are these A-TRIP principles applied to Function Test or System Test?
Andy and Dave, thanks for being with us here this week.
 
Ranch Hand
Posts: 3178
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Doug Wang:
Are these A-TRIP principles applied to Function Test or System Test?
Andy and Dave, thanks for being with us here this week.


Of course, the book is about Unit Testing and A-TRIP mentioned in the book is applied to Unit Testing...
 
Ranch Hand
Posts: 8944
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ko Ko Naing:

Of course, the book is about Unit Testing and A-TRIP mentioned in the book is applied to Unit Testing...


Are there chapters on System/Intgeration testing.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Pradeep Bhat:
Are there chapters on System/Intgeration testing.

No.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic