Automation: How do you avoid duplication of development work?

(Heather) #1

Stephen posted this in the Slack channel and kindly agreed to it also being shared here to get a greater range of answers:

“So, heres a thought for discussion -> Automated Testing. How do you avoid duplication of development work (ie by basically writing the same code to test the function as the function itself) and is it sometimes worth doing that anyway?”

He started with a response to the second part:

“I think so sometimes. I’ve just been testing an API function that was a 40 odd cell column of options/combinations (comprising about 4k permutations of inputs) with caveats that forced you down or right a column . I wrote it as a 400 odd line if statement and found that we had differing outputs on about 200/4k (5%) where we had interpreted the spec differently due to previously unnoticed spec ambiguity”

Some interesting replies so far, the highlight being a general consensus that individual functions should be covered by unit testing and behaviours should be focused on by testing.

What are your thoughts on this?

(Greg) #2

The first place he might want to look for problems is here:

facepalm

(Anna) #3

I thought this post by a colleague makes interesting related reading: http://testingchef.blogspot.co.uk/2016/07/a-hole-in-net.html

(Suresh) #4

Try Page Object Framework To Avoid Duplicate Work

Use global variable inside of local variable to avoid duplicate work

(Alejandro) #6

Code duplication is one of the typical code smell an expert developer reduces using refactoring and good programming practices.

Testing Code is not always considered as well as Production Code.

Feeling the same discomfort working on Automation Code means that you are trying to apply a good development process.
At a glance can be considered a good approach, but not always is the better choice.

In my short but intense experience I consider the expected life cycle of the code I’m working on.

The crux is trusting the result of refactoring, the resulting framework and the shared components.

WHO WILL TEST THE TEST CODE?

My solution?
Split the automation like Moses did.
Putting under CI the Test Framework Code, working on it like a product (versioning, releases, defect, backlog).
The pure automation, at the end, has a shorter life cycle and I prefer to duplicate (fast automation instead of long life automation).