Timeline for Should test cases contain business logic?
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 29, 2016 at 6:51 | vote | accept | Andrejs | ||
| Sep 20, 2016 at 12:49 | comment | added | Kate Paulk | @AndreyDoronin - there was a problem, and it got better by putting business logic in the test cases (this is the mitigation strategy to make the problem less problematic). It's flawed because it causes maintenance hell etc. but you're not going to change it unless you can work with your superior to find a better way to fix the problem he's trying to fix with business logic in test cases. | |
| Sep 20, 2016 at 12:43 | comment | added | Andrejs | "move away from what is almost certainly a flawed mitigation strategy" - could you elaborate on that please? | |
| Sep 20, 2016 at 12:42 | comment | added | Andrejs | Yeah, pardon, my background is that I automate my own manual TCs, so easy for me to speak. "Automators who understand the business logic can craft their code to be more efficien" -- so I'll agree to that :) | |
| Sep 20, 2016 at 12:37 | comment | added | Kate Paulk | @AndreyDoronin - you won't see any arguments from me about maintenance hell! As I said, ideally everything should be documented exactly once. The issue is that your superior has found this maintenance nightmare to be helpful, so is keeping it. You need to know the underlying problem before you can help to move away from what is almost certainly a flawed mitigation strategy | |
| Sep 20, 2016 at 12:35 | comment | added | Kate Paulk |
@AndreyDoronin - I disagree that test automators only need to know what to click and what to assert. That produces maintenance hell in the automation code (I speak from experience here...). Automators who understand the business logic can craft their code to be more efficient and make sure they assert the correct things.
|
|
| Sep 20, 2016 at 12:32 | comment | added | Andrejs | Also, spreading duplication over a 1000 test cases causes 1) maintenance hell 2) Invalid bugs because "oops, someone forgot to update that duplicate business logic paragraph in the test case" | |
| Sep 20, 2016 at 12:31 | comment | added | Andrejs |
Great answer. Thanks. Note re Automated regression - IMO, test automators actually just need to know what to click and what then to assert. If they want to know more - link to the requirement ticket is there. "everything should be documented exactly once and then referenced" -- yes, that's what the team should strive for, and not argue against the DRY principle with "nobody reads that bit".
|
|
| Sep 20, 2016 at 12:22 | history | answered | Kate Paulk | CC BY-SA 3.0 |