Please let me set your expectations from scratch. I really want to highlight the fact that I’m NOT an Automated Testing Guru, neither a testing-driven developer. I wrote a few tests in my “coding” life, and half of them I’ve already deleted because I’m way too embarrassed to showcase them. However, I see the added value they bring, and honestly, I want to pitch my colleagues at PixelGrade that we should take advantage of automatic tests. We want to deliver flawless WordPress products from top to toe.
Now I’m going to cover the general idea, a specific terminology (which, btw, I find it important), and some thoughts about the automatic tests before using them.
Test-driven development – TDD
It’s a methodology which promotes the development in very short cycles and creates a test case for each one.
Basically, it requires you to write tests first, make sure they fail, and after that, code and refactor until they pass.
It’s a software testing method which breaks the software in tiny pieces (units) which can be tested individually.
It’s also the mechanism that stands behind some methodologies extreme programming or …
Regressing Tests &
A method which is testing software, already released, that still performs correctly after getting some changes (new features of bug fixes).
Continuous Integration &
It can be narrowed to tools (like Travis, CircleCI or GitLab) that help us run automated builds and test in order to be able to quickly deliver a product version suitable for release.
Until recently we had an integration with Travis for our themes, but it didn’t make too much fuss. Just checking the PHP syntax to be correct until the 5.2.4 version. Personally, I think it is a time saver since it notifies us whenever we broke syntax and miss it (believe me it is happening twice per month). The struggles avoided by our products are significant, and this is far more important than some extra spare hours.
Presumption – Testing is slow!
I always thought that if I’m going to write code and also ensure tests, it will slow me down. It will definitely slow your rhythm because the methodology slows you down, the tests will run slowly, everything is like a tortoise in this process. Well, at least the product quality should catch some speed.
I’m gonna bust this myth and prove you with data tha … no I won’t .. to process is still slow, but there must be a reason why programmers are building software with testable code since ages:
- TDD is a common subject since 2003, and even then it was about rediscovering an ancient technique
- Unit tests are a thing since 1976 according to the AgileAlliance
People are still using them, actually since 1976, I’m not sure if my mom was born at that time. Nowadays they are already a requirement because they’ve added a layer of quality to work.
If a factory is building car pieces with robots, those robots have work limits and sensors to prevent Mr. Terminator shooting with lasers into employees to revenge his race –– the same is with QA tests.
This is our case, we need to test at any time the fact that our products are working between our acceptance limits.
Did I mention Agile somewhere above, why?
Q: Wasn’t that about delivering a Minimum viable product fast? The testing process is getting us slow in development it’s far away from being Agile, right?
A: Well yeah, the lethargy won’t disappear, but if you take a look over the Agile Glossary you will see lots of references to testing technics. Why is that?
Because Agile is not about delivering fast a broken product, is almost the opposite(if you except the speed) the Agile Manifesto is based on twelve principles, here are 4 of them:
- Customer satisfaction by early and continuous delivery of valuable software
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Working software is delivered frequently (weeks rather than months)
I’ve changed the order for my needs, but how can you provide all these without a strong testing environment and tools? You need to frequently deliver updates to improve your products, but also keep them high quality and I can bet all my money that Customer satisfaction will drop fast if you bring a feature and ruin another by mistake.
Before we go on, can you tell me what kind of feeling this quote gives you?
We want to spend all our time coding. Remember, real programmers don’t write documentation.
This was a counter-manifesto against Agile around 2001. However, I think there is an association between the documentation and automated tests. Moreover, I think this deeply contradicts some strong programming principles like:
DRY – Don’t Repeat Yourself
The redundancy wouldn’t drop when you write a Documentation about something that is getting annoyingly repeated over and over again?
KISS – Keep It Stupid and Simple
Isn’t simple to read a Documentation and quickly start programming with those principles in mind? I know it’s hard to build a good-writtenn documentation, but it is making the process simple and smooth.
YAGNI – You Aren’t Gonna Need It
I dare to state that documentation can help you identify faster what you don’t need!
What could go wrong?
- Tests requirements are notorious for being misunderstood.
- The necessity of rewriting the test, after making changes to the project!
- Lack of technical skills for the writing of tests.
- Outsourced testers know nothing about my project.
- Outsourced testers have lack of experience
Another risk in writing tests is that they can get redundant and boring(but what good thing in life comes without sacrifices?).
A few years ago I had a colleague apartment, also a programmer, who told me that he hates writing unit tests and this GIF describes him at best when he does this boring task.
Benefits for automated testing
As a product, I think that the benefits are already clear. The quality assurance adds a great layer of a product, it puts a motorcycle leather on a software which makes it look so badass.
When we talk about a team, I’ll risk my nuts and say that everybody should benefit from automated tests:
- Developers – they should be less stressed if there is another testing entity(sometimes a better one) aside their own and escape from the Impostor Syndrome
- Designers – Every designer has some acceptance limits for every project, wouldn’t help them to know that further development won’t break those limits? Or at least to accept that tests will fail when this happens.
- Custom Service Heros – Who else encounters most of the problems of a product? They are also the happiest ones when an automated tool prevents the same problem going into production and producing tickets again.
- Marketing and Copywriting –Automated testing should help us keeping our promises to our clients. Isn’t this a good thing to brag about and a strong trigger to keep happy clients on board?
Let’s get practical
In my opinion, they lack Behat so it could be a little user-friendly … but if I can really dare to dream … imagine combining them with a Speech Recognition Software.
Visual regression tests like Wraith or Gemini
These kinds of tests fall in the End2End methodology area which endorses the product testing in a real environment(not just a terminal or a PHP request). In web development, this means we have to emulate a browser and make the automated system trigger some actions like authentification add a comment or even buy a product.
A good practical example can be the guide made by Kate Kligman @ Pantheon
Another good and powerful example can be gemini
Another End2End tester is NightWatch – and you can see this tutorial a little piece about what it can do.
And above all … the tests should be Continuously Integrated
Don’t forget about CI! All the test you are doing they should be able to be executed on tools like Travis or GitLab. They are time savers when they are building tests exactly in the moment that you commit a change.
That’s it for now, let’s hope I can talk about this subject in the future articles,