Testing
Kalamuna Testing Ethos
What/when do we test?
- Backend to Frontend Components that we can reuse. Eg kalamuna/a11y-toolbar
- If you’re going to be testing a piece of functionality more than twice.
- If we own the project.
- If it’s a contrib/vendor module that has existing tests
Coding standards are important.
- We need to have code linting across all technologies (PHP/JS/whatever)
- EditorConfig should be included in each project.
- ESLint for Drupal Standards
Tests are for clients too.
- When clients report a bug, create a test for it. Develop until it’s fixed. Give the client access to the tests (perhaps Selenium IDE tests or Behat).
- Expose test runner results. Show web driver screenshots of errors (perhaps share in folder to client).
Don’t let testing block development.
- We’ll start simple with tools like Selenium IDE, get more complex as opportunities.
- We want to make delivery quicker and safer.
Testing Areas
HTML Validation
Testing to make sure the HTML coming out of the template is valid.
Javascript
Testing Tools
- Mocha (New hotness, more advanced than Jasmine)
- Jasmine
- Karma (formerly Testum, runner for Jasmine)
Browser Drivers
- PhantomJS
- ZombieJS
PHP
PHPUnit for new tests, leverage existing Simpletest
Testing Tools
Simpletest → D7 (D8 will accept)
How useful are all the Simpletest unit tests shipped with D7 core/contrib to us in our projects?
Would they be more helpful if we’re using REAL site data to generate fixtures w/SimpleTest Fixture?
PHPUnit → D8
ClassLoader is required for PHPUnit
Resources
, multiple selections available,
Related content
Circle CI x WPEngine – DEPRECATED
Circle CI x WPEngine – DEPRECATED
Read with this
Kalamuna Support Client Onboarding Checklist (WordPress flavor)
Kalamuna Support Client Onboarding Checklist (WordPress flavor)
More like this
Setup CloudFlare
Setup CloudFlare
Read with this
Working with client databases
Working with client databases
Read with this
Git Workflow
Git Workflow
More like this