Test Expressivity

From CitconWiki
Revision as of 15:50, 24 August 2013 by Emilsit (talk | contribs) (Raw notes)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

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
  • 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,