---
# System prepended metadata

title: Write Better Test Cases

---

# Write Better Test Cases

- [Naming](https://github.com/robotframework/HowToWriteGoodTestCases/blob/master/HowToWriteGoodTestCases.rst)
- [Dos and Don'ts](https://www.slideshare.net/pekkaklarck/robot-framework-dos-and-donts)
- [Writing better Gherkin](https://cucumber.io/docs/bdd/better-gherkin/)
    - Scenarios describe the behaviour, but not the implementation.
        - Fnctional requirements are features: scenarios should describe the intended behaviour of the system(what), not the implementation.
        - Procedures belong in the implementation details(how).
        
        That way, when the implementation of a feature changes, you’ll only need to change the process steps behind the scenes.
        The behaviour does not have to change just because the implementation does. 
        In fact, a good question to ask yourself when writing a feature clause is: “Will this wording need to change if the implementation does?”. 
        If the answer is “Yes”, then you should rework it avoiding implementation specific details.
        
    - Imperative style v.s. Declarative style(better)
        
        Declarative style describes the behaviour of the application, rather than the implementation details.
        With a declarative style, each step communicates an idea, but the exact values aren’t specified.
        The details of how the user interacts with the system are specified in the step definitions (the automation code that interacts with the system).
        In addition, having too many implementation details in a scenario, makes it harder to understand the intended behaviour it illustrates.