I’m at WordCamp London - live-blogging some of the talks
- Strategy for handling a tight deadline: Piles of acceptance tests
- Disagreement between different languages on what unit tests mean
- Focus on tools and concepts not methodology
- Codececption - does a lot of things, mocking etc. php testing framework
- Acceptance testing: commands like
amOnPage,see,fillField - Define scenarios: login, fill in form and submit etc.
- Generates reports in: console, html, xml (Ick!)
- Can use different drivers: WebDriver (fast, headless, no js, basically does the equivalend of cURL), Selenium (Slow, but drives the actual browser: can be hard to set up), PhantomJS (headless, runs js)
- Functional testing: sits alongside acceptance testing
- Test the interactions between units - integrations
- Ignore UI and JS - make posts directly: don’t emulate the browser - just call endpoints (incl. ajax) directly
- Can also be used to test apis/rss, cli, sending email, can also test xml-rpc
- We’ll be interacting with the database, so we need to set up and tear down
data
- WP-Browser handles these database interactions (i.e. you can directly insert data)
- Approach for setup and teardown: you can run a shell script before and after a codeception test, so setup wp-cli scripts to do the database setup and teardown
- Re-usable code in Codeception: Step objects (collections of related steps to DRY up tests?)
- Helpers, Modules
- Refactoring strategy: Acceptance tests allow you to refactor your unit tests with confidence, (which allows you to refactor your code with confidence)
- Question: How to not couple the tests to e.g. the names of field names
- Strategy: create a page object which wraps up those IDs, so that you only have one point where you need to change these
- Makes it slightly harder for non-developers to do the changes (does it though??), but makes it much more maintainable