My grandmother was an old-school Italian grandmother from southern Italy. Imagine an old woman, short, with a handkerchief around her head. She didn't speak a lick of English and was slightly off her rocker.
Or better yet, think of the scene in Star Wars: The Empire Strikes Back when Luke first meets Yoda on Dagobah.
All Luke sees is an odd, old creature speaking gibberish messing around with all his stuff.
Well, that was like my Grandmother in a grocery store.
It was such a sight to see that whenever my mom took her shopping I had to go. I couldn't take my eyes off her.
Grandma would move through the produce section squeezing all the fruits and vegetables, smelling the tomatoes, knocking on the cantaloupes.
Giving the eggplants the evil eye.
If the fruits or vegetables didn't pass my grandmother's smell and squeeze tests, they did not go into her carriage.
What I didn't know back then was that my Grandma was inadvertently teaching me a clean code principle that I now apply to all my test automation code. This principle is usually called Code Smells.
Automation Testing Code Smells
Code smells are indicators that something in your code is not right. Being aware of indicators like this is the first step to improving your test automation.
My Grandmother, by using her keenly honed senses, was able to tell before buying whether or not a not a piece of fruit would be good. Likewise, developers of test automation code (or any other code) also need to build up their code senses so they can quickly sniff out bad and good software designs.
Some examples of code smell might be either a long method that should be broken up into smaller methods, or duplicated code, which is both signs that something is wrong.
When I do code reviews and notice small things like someone not even naming a package to the Java standard or misspellings, I always spend extra time on their reviews because I know that their code most likely has deeper issues. If they can't take care of the small things, how can I trust them to take care of the more complicated things?
“Smells” like these serve as pointers toward larger, underlying issues. Kind of like looking for signs on a piece of fruit – for instance, if the skin of a peach or mango is wrinkled, it has obviously begun to spoil.
Listen to You're Automated and Unit Tests
Matt Wayne, author of The Cucumber Book, also calls this concept “listening to the tests.”
The feedback you get from your tests can come on a number of different levels. If they're taking a long time to run, for instance, that is feedback to you; it is information being communicated to you that you need to deal with. And the way to address it is not just by figuring out ways to parallelize the tests or running them using a headless browser. Those actions are really just kind of putting band-aids over the problem.
An issue like a slow build occurs because you've got a big lump of architecture that you haven't broken up properly; it means that you need to allocate the tests to more specific areas of that architecture so they can run faster and be more focused.
My main tip would be that when you're running tests against your system, be sure you are really listening to those tests. If something is hard to test, if something's slow to test, if something's unreliable to test, there's probably a deeper issue there that you need to look for.
Just as eating spoiled fruit can make you sick, test automation code that smells can cause you all kinds of maintenance and reliability headaches. So the next time you're creating an automation framework, think of my Grandma. Make sure nothing bad gets into your production code. Ciao!
Listen up
This post idea came out of a Mother's Day special episode of Test Talks that I recently did called What my Mother taught me about Test Automation and Life. You can listen to it here==>http://www.testtalks.com/51
