name: Frontend Testing Redux class: middle, center
- Unit testing (Faster, logic tested in isolation from the DOM)
- When this "function X" is run with "Y parameters", I expect "Z results"
- End to End testing (Robot QA Friend that click around your app)
- When a user clicks on "element X", I expect "element Y" to change in the following way.
Previously on Adventures in frontend testing: http://gistdeck.github.io/RyanParsley/e9733f8d472ae7778346#1
- Ford - GUX - https://vcs.rockfishinteractive.com/projects/FORD/repos/ford-gux-build-price/browse/test/e2e/spec.js
- Fidelity - Social Security (https://vcs.rockfishinteractive.com/projects/FID/repos/fidelity-social-security/browse/test/unit/app/state/state.spec.js)
- Fidelity - POSA (https://vcs.rockfishinteractive.com/users/ryan.parsley/repos/fidelity-posa/browse/test/unit/app/app.spec.js)
- Cincinnati Bell - Connect Landing - https://vcs.rockfishinteractive.com/users/ryan.parsley/repos/cincy-bell-connect-landing/browse/test/e2e/demo.spec.js
- Ford - DRE - https://vcs.rockfishinteractive.com/projects/FORD/repos/ford-dre/browse/test/unit/app/wizard/wizard.spec.js?at=refs%2Fheads%2Fdevelop (just getting started)
- Less noisy/distracting that a "suite" of console.logs
- Less embarassing than a human pointing out my many faults
- Semi-automatic code documentation
- Regression coverage
- With unit testing, you need to understand injection and how digest works more than simply using angular (this is a feature not a bug)
- With E2E testing, it's... non-trivial to get selenium running on the server in a reliable way
- When I want/need persistant console.log messages
- When the "API" settles down a bit
- When I fear I'm about to break something