How to create quality code in WordPress plugins and themes using static code analysis, automatic unit testing, E2E testing, TravisCI\Jenkins and other tools.
2. WHO AM I
• Web developer at HPE Live Network Content Marketplace.
• Working on LAMP MEAN stacks.
• Working on WordPress since V1.5
• Owner of internet-Israel.com.
• Father of 4 children.
• @barzik
4. QUALITY CODE
• Fact #1 – everyone say that quality is important.
• Fact #2 – most dev doesn’t do anything to improve their
quality.
• Fact #3 – Most clients doesn’t care about quality.
• Fact #4 – Clients that does, will pay for it.
5. WHY DO WE NEED QUALITY?
1. maintainable.
2. robust.
3. Secured.
4. Fast.
6. WHO WILL NOT NEED IT
• Landing pages.
• Small scale sites.
• People that love to pay for modification of cod.
7. WHO WILL NEED IT
• Real products.
• Big sites (really big) that we need to maintain for a long time.
• Secured sites.
8. QUALITY CAN BE MEASURED
• Show Demand it:
• Your boilerplatesgenerators
• Your CI process.
• Your static analysis data.
• Your security tests results.
• Your automated tests data:
• Code coverage report
• E2E scenario
• Your performance:
• Benchmark reports.
11. MEET THE BOILERPLATES FOR THEMES AND
PLUGINS
• The leading boilerplate for plugins is:
https://github.com/DevinVinson/WordPress-Plugin-Boilerplate
[Or just search WordPress plugin boilerplate]
12. WHY IT IS BEST TO USE BOILERPLATE?
• Based on experience of 59 contributors.
• Updated frequently.
• OOP, made with the best practices.
13. USE SASS OR LESS IN YOUR TEMPLATES
• Much easier to maintain (if it is a big website or something that
will be maintained and developed for a long time).
• All modern web products built with it.
• All CSS frameworks compiled from it.
15. WORDPRESS CODING STANDARDS
• Created by Matt Mullenweg himself.
• For PHP, CSS, JavaScript and HTML.
• Can be found it WordPress Core developer’s handbook
16. WHY DO WE NEED IT?
• avoid common coding errors
• improve the readability of code
• simplify modification
They ensure that files within the project appear as if they were
created by a single person.
17. MEET STATIC CODE ANALYSIS FOR PHP–
PHPCS
• PHP_CodeSniffer module.
• Can be installed with pear.
• Will test WordPress code combined with WordPress-Coding-
Standards plugin.
18. INSTALL IS EASY
> pear install PHP_CodeSniffer
> phpcs -i
The installed coding standards are PHPCS, Squiz, PSR2, MySource,
PEAR, Zend and PSR1
> cd c:wpcs
> git clone -b master https://github.com/WordPress-Coding-
Standards/WordPress-Coding-Standards.git wpcs
> phpcs --config-set installed_paths c:pathtowpcs
> phpcs -i
The installed coding standards are PHPCS, Squiz, PSR2, MySource,
PEAR, Zend, PSR1, WordPress, WordPress-VIP, WordPress-Core,
WordPress-Docs and WordPress-Extra
19. RUNNING PHPCS + WORDPRESS IS EASY
FILE: /var/www/html/github/wp-notice/tests/bootstrap.php
----------------------------------------------------------------------
FOUND 6 ERRORS AFFECTING 5 LINES
----------------------------------------------------------------------
2 | ERROR | [ ] Missing file doc comment
4 | ERROR | [x] First condition of a multi-line IF statement must
| | directly follow the opening parenthesis
19 | ERROR | [ ] Missing function doc comment
19 | ERROR | [ ] Function name "_manually_load_plugin" is invalid;
| | only private methods should be prefixed with an
| | underscore
21 | ERROR | [x] File is being conditionally included; use "include"
| | instead
22 | ERROR | [x] File is being conditionally included; use "include"
| | instead
----------------------------------------------------------------------
PHPCBF CAN FIX THE 3 MARKED SNIFF VIOLATIONS AUTOMATICALLY
----------------------------------------------------------------------
20. MORE DATA ON INSTALLING CAN BE
FOUND HERE;
• https://internet-israel.com/?p=5980
21. MEET JAVASCRIPT CODING STANDARDS
• Jshint or eslint (I prefer eslint).
• Working with npm directly from the command line.
• Working with gruntgulp.
22. YOU CAN DO STATIC CODE ANALYSIS ON
EVERYTHING
• SCSSlint will test your SCSS code against code standards.
• HTML linters will lint your HTML templates.
All can be run from console or with gruntgulp.
23. SECURITY STATIC TEXT ANALYSIS
• phpcs is testing against CSRF, XSS and SQL injection.
• Use watchtower static code analysis tools to highlight code
issues.
24. FORGET ALL THE CONSOLE COMMANDS!
USE GRUNT OR GULP
Use task runner
> phpcs --standard=WordPress ./**/*.php
> eslint -c ~/my-eslint.json ./**/*.js
> scss-lint ./**/*.css.scss
25. JAVASCRIPT TASKS RUNNER WILL HELP YOU
RUN EVERYTHING!
• Create a build process for WordPress.
• Orchestrate all static code analysis.
• Print out a report.
• Do it on local or on remote!
26. PRO TIPS
• Using intellij? There is native support of WordPress coding
conventions in PHP, JS or HTML
• Tie in the gruntgulp with githooks or SVN hooks.
27. AUTOMATED TESTING
• Help fight regression.
• Help verifying that everything will work against new versions of
WordPress.
• Help testing it in different version of PHP, Linux updates, etc.
28. UNIT TESTING
• Unit testing tests the code it self, functions, class, etc.,
• It should be separated from 3rd party and emulating those.
29. PHP UNIT TESTING
• PHP unit testing is done by PHPUnit + WordPress Develop.
• WordPress develop is like all WordPress + automated tests suite
that you can mount plugin and template to.
• Mounting is easy with this example:
https://github.com/tierra/wordpress-plugin-tests
It is done by ONE XML file and ONE bootstrap PHP
30. JAVASCRIPT UNIT TESTING
• In WordPress it is done by Qunit, but there are a lot of
JavaScript testing framework and runner.
• I use karma runner + Jasmine Mocha.
31. MEASURING THE AUTOMATIC TESTS
• Meet coverage report!
• Generate it by small tweaks to the XML of the phpUnit
33. SOME TIPS REGARDING COVERAGE REPORT
• You cannot achieve 100%
• Google engineers stated that above 85% is more than enough.
• Branches are very important.
• Demand minimum coverage!
34. END TO END TESTS
• Emulate users
• Done against mock database sandbox 3rd party API
• Done on multiple browsers
35. LEADING TOOLS
• Selenium (easy to custom & install & to run, limited
functionality)
• LeanFT (Easy to install & run, full functionality, costs money)
36. TESTING CAN BE RUN ON DIFFERENT
ENVIRONMENTS
• You can run The testing on every WordPress dev version that
you want.4
• You can orchestrate those with automatic build process.
38. BUILD SYSTEMS
• Travis is used for CI – it is fast to work with, very easy to set up
and work with WordPress.
• Jenkins is CICD tool and it is quite complicated and require
devop knowledge.
40. PERFORMANCE
• Performance can be tested and measured by several tools.
• Meet apache benchmark.
• Easy to install and run (on Linux)
ab -n 100 -c 5 http://mysite.dev/?p=10
C is concurrent user,
n is number of pings.
41. PERFORMANCE REPORT
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 2.1 0 11
Processing: 733 5078 1515.8 4786 13425
Waiting: 599 4097 1138.2 3871 11915
Total: 735 5079 1515.6 4786 13435
More information on report
can be found at my site:
42. SUMMARY
• Quality does not mean anything without defining means to
achieve it.
There is HUGE difference between saying “My product is in the
best quality” and “My product is based on the most modern
boilerplates, using SASS, tested with static code analysis for
standards and security and have more than 70% coverage”.
• Some quality is better than no quality.
43. CONNECT WITH ME!
• Just search “Ran Bar-Zik” On Facebook, Twitter, LinkedIn or
GitHub :)