Test Expressivity
Present: Emil, Jason, Andy, Rob, Monica
- How should you organize your test suites?
- During development?
- Different from when they are considered regression tests?
- Should they be weeded out
- end to end tests
- Should you even have them?
- How many?
- The test pyramid (http://martinfowler.com/bliki/TestPyramid.html)
- Having requirements docs and test case docs
- Very common, yet it's problematic; especially if they're at the same level of detail/abstraction
- Challenges with dispersed teams
- Clarifying tests with comments is not expressive? not expressive enough?
- You should be able to show your business people your test code...
- And they should be able to understand them
Howto build Maintainable test automation framework. How do you make it understandable. Reuse and abstraction. How much do you invest in these frameworks?
Writing a book. Reasoning. Write what you want to read. How to sell it to other devs?
How long lived is the business? How does test express what the business needs? Don't throw away tests that have taught you about the business.
Don't align feature files with stories or work units. Write them along with the domain.
Validate the tests? How do you have confidence that the test describes the behavior?
Three amigos - business, tester, dev - all review stuff together. Imperative tests are hard for business people to think about.
Review test code with business side Can you fold the code and get a good sense of it?
Cucumber ... Do people like it?
Do people understand the requirements?
- be declarative
- use the domain language
- does the test explain why this test is interesting? Can you hide what is not interesting?
Can you build reusable steps. Good logs and assertions to help find failures,
