Advertisement
Guest User

Untitled

a guest
Jul 21st, 2019
71
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.35 KB | None | 0 0
  1. | tag | runs in ui with mocked domain | runs against pure domain | runs in itegration test |
  2. |-----------|-------------------------------|--------------------------|-------------------------|
  3. | none | if available | yes | no |
  4. | @ui | yes | no | no |
  5. | @critical | yes | yes | yes |
  6. | @critical and @ui | yes | no | yes |
  7. | @external | no | no | yes |
  8.  
  9. The basic idea is that all tests should run against the domain, unless those tests are env specific (eg. relating to network conditions, the currently selected view, interacting with an external api, testing the database or other io-bound dependencies, etc.)
  10.  
  11. Some tests are critical and should be run in every environment they're applicable to (generally this means running them in all 3 environments)
  12.  
  13. End result is n tags for environments (to limit tests to only be run against environments they work against) and 1 tag for critical tests.
  14.  
  15. For more complex workflows you could just have `@env-only` to mean 'can/should only be run in `env`' and `@env` to mean 'should be run in env'
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement