Automated Testing Patterns and Smells

Google Tech Talks
March, 6 2008
ABSTRACT
The extensive use of automated testing has been a breakthrough practice in improving the quality of software produced by developers. By now, many companies have experimented with the use of automated functional tests and unit tests. Those that have had good experiences with it rave about it and cannot imagine having been successful without their automated tests. But for every success story there are many (often untold) stories of disappointment. What separates the success stories from these disappointments?
In this presentation Gerard describes a number of common problems encountered when writing and running automated unit and functional tests. He characterizes the problems in the form of "test smells", describes their root causes, and suggests possible solutions expressed in the form of patterns. Although these patterns and smells originated from the developer community's use of xUnit for automated unit testing, many of these smells and patterns are equally applicable to automated functional/acceptance tests using tools such as Watir and some even apply to Recorded Test tools such as Mercury's QuickTest. While many of the practices he describes are directly actionable by developers or testers, many also require action from a supportive manager and/or system architect to be achievable.
Speaker: Gerard Meszaros
Gerard Meszaros is a Calgary-based consultant specializing is agile development processes. Gerard started his career in Ottawa working at Bell Northern Research building telephone switching software. He left Ottawa in 1995 to join ClearStream Consulting where he built his first unit testing framework in 1996 and has been doing automated unit testing ever since. He is an expert in test automation patterns, refactoring of software and tests, and design for testability. Gerard has applied automated unit and acceptance testing on projects ranging from full-on eXtreme Programming to traditional waterfall development and technologies ranging from Java, Smalltalk and Ruby to PLSQL stored procedures and SAP's ABAP. He is the author of the book xUnit Test Patterns -- Refactoring Test Code published by Addison Wesley Professional in the Martin Fowler Signature Series.

[@gmoschwarz]

"About the same unit test code as production code." That's really a pearl. How insightful and at the same time, how simple.

[@MarcelPopescu]

The "meat" of this talk is IMMENSELY useful. I sincerely hope he can make it more dynamic or something - the monotone is a huge drawback. (Seriously, the refactoring he does on the test, progressively reducing it from 30+ lines down to a few is fantastic.)

[@ConradBraam]

When we look at What Gerard Meszaros is describing in automated testing gotchas, the gotchas not related to coding style and refactoring are all things manual testers do already. Smells emanating from random behaviors, fragility, uncertainty coming from the appearance of your fixtures (environment setup steps) and test run wars are real manual test problems too. The issue is that automation engineers really must guard especially well against making these mistakes, to keep testing cost down. Maintainability debt is your greatest enemy, and where I personally prefer less not more automation - "too many test-cases" is a smell I detect, one not explicitly mentioned in this talk.
I'll be looking for a copy of xUnit Test Patterns!

[@johnbarley4921]

Very useful video. Many thanks to the author.
Also, let me recommend "Blisk Browser" as a very powerfull tool for testing

[@MrsPoopra]

@Quinzio,....s i agree wid u...can anyone pls give me sme practical examples on different types of testing...

[@ravilahane11]

NICE ONE@

[@ornous]

Hopefully, you've got your answer already.
If anyone else needs to know:
The Author is Gerard Meszaros. His book is called xUnit Test Patterns published with Addison Wesley and signed by Martin Fowler.

[@alexandersharma]

Who is the author of this talk. and what book did he write?

[@EminoMeneko]

Where would you try to find the information?
When I was a student one of my IT teacher told something like this: "Information: Either you know it, either you know where to find it"
Hints: Beginning of presentations often start with presenter's name + here at least the guy put his name on every slide at the bottom.

[@RapaFan]

If he stands between projector and the screen why is his face dark!?

[@EminoMeneko]

The only explanation I could give is the projector has a very untypical angle to display content.
Or he is not actually where we seem to see him. Basically illusion on his position.

[@IntoleranceRecords]

what the heck is this? my test doesn't smell.

[@thomasf.9869]

Why don't more software engineers code their tests like this?? Sigh

[@chriskerley1508]

There is STRONG pressure to just get it done, what happens in a lot of cases is people are pushed to get working code and aren't given enough time to make good tests. There will never be enough time to test every path in the code, so its a trade-off. What's more important? Hitting the deadline? ensuring maintainability? Is a bug disastrous or just an annoyance? its depends on the requirements.
TDD is also very VERY addictive and fun. BONUS if you can get test results in under 0.1 seconds, it literally feels like a video game. Seriously if any developer wants to improve their happiness factor at work, they should work on getting there test framework to return results almost immediately, it is a night an day difference in the level of engagement of the task.

[@SkyManager]

It is very annoying about your camera man frequently zooming in and out. Please do not do that any more.

[@Quinzio]

All this theoretical talk without any example is just useless.
This is practical worl, we need examples.

[@EminoMeneko]

That's true. There is too few examples compared to what is provided when you lack experience mostly. If you wen t through similar situations you can relate to these however.