layering your tests

When ever my wife leaves our house alone to me for a week or so, things start piling around. Cloths will be lying on the floor left exactly where I took then off, sink will be full, layer of dust in the floor, mobile/laptop/tablets/purse/keys hidden under pillow/bed sheets/pillow/shoes!!....

So when I look around for a nail cutter, obviously I'll not be able to locate it. After enough googling around my house, I'll go buy a new a nail cutter, which would eventually get lost into those black holes in my house.

My wife comes back, scolds me for the mess I created, make me slog with her in cleaning it. Oops she finds the extra nail cutter, give an other round of bash. I end up buying some gifts in consoling her.

Moral of the story: Keep thing organised, though it takes an extra effort at first place, so you can avoid

• living along with the mess
• search for thing you want
• investing (cost/time) on getting some thing that you have already
• cost/time spent on cleaning
• penalty we pay for creating the mess
• and mostly importantly, those bitter moments in life.

Enough of my story, coming to work, in an automation code base, if we put things where ever we want, we will end up repeating my story at house.
 

For example, if you are writing a function to delete a file if it exist and create a new one. And it part of some test and it is not abstracted into proper class and method. When your team mate wants same function, he/she would google to find how to implement the functionality, and may do in a different way than yours, since they will not be able to see that this already exist.
 

There are multiple reasons why this mess gets created

• Test suite is not organised enough
• Though with a good framework in place, lake of discipline, awareness or skill level.

The ways in which we can avoid such mess are

• Create modules/projects/namespace that does a specific work. Like tests(will hold your tests), application (operation in a application like login, create user), file operations, test tool(implements button click, type text, select option, drag drop). "Page Object Model" is a good starting point
• Define contracts between the modules. Ex. test tool module should only be used in application module and not in tests. In other words button click in your test class is wrong, they should be in your application module.
• Educate you team about the structures. Pair with them in writing few test, so they would learn.
• Use custom checks as part of your build to find module leakages and if found fail the build. Ex, use a parser to find if there are any button click in you test class, and if found fail the build

more to come...