Some time ago, I published a blog on 1 of the 8 points that ExtDN has phrased for creating proper Magento extensions: To use composer. These DOs for Magento extension development are part of an effort to increase overall extension quality. I wanted to write on all 8 points, but ... well, life. Here is a discussion of another point: To write tests. Right in time for MageTestFest.

To write tests or not to write tests

First of all, to quote from the original ExtDN whitepaper first: Testing becomes a habit that pays off in the long run. Make sure functionality is tested using integration tests and functional tests. Remember that unit tests make more sense with isolated code, integration tests make more sense with code that touches the rest of Magento.

Now, there's more to this than just a simple paragraph: Each line could lead to additional comments. It's why it deserves a blog, I guess.

Testing becomes a habit

I've talked with various well-known Magento gurus in the field of testing on this topic - and they are in the line-up of speakers for MageTestFest: Testing should be embraced, it makes sense, everybody gets the main point. But still, some developers that try out practices like TDD give it up after a while: It is too much work. You tend to forget about testing, because it is easier to work on the fix right away.

This is the difficulty of changing your workflow. At first, it is hard. And it is easy to go back to the old route of writing untested code and just relying on your expertise to make it work. But this is the point: It needs to become a habit. It doesn't start as a habit. It needs to become a habit.

... that pays off in the long run

And it takes time before this is actually a habit. How much time depends on the person. It could be a couple of days, it could take months. But as soon as you delay it, it will take even longer.

However, there is a promise: If you embrace testing as an habit, it pays off. Your code will contain less bugs. Less bugs means more fun. And it also means that you spend less time on old code, more time on new stuff. Testing allows you to grow as a developer. There is so much to win. But no one should tell you that you get this habit for free: It requires practicing.

Integration tests & functional tests

The ExtDN whitepaper is not meant for any developer for any platform: It is specifically meant for Magento extension developers. While an extension could sometimes incorporate library code, where unit tests have a vital rule, the main feature of an extension is to extend the functionality of Magento. To guarantee that this works, make sure functionality is tested using integration tests and functional tests. And note that this does not only count for third party extensions, but your own extensions as well.

Having only unit tests in an extension shows that something is missing: A module is rarely a stand-alone thing. Having only integration tests suggests that there is only internal logic, not changing anything in the output of the system: This might be the case. But most extensions have internal logic that changes the output of Magento, which means both integration tests and functional tests (like with MFTF) have a place.

TDD?

Funnily enough, TDD (Test Driven Development) is not mentioned anywhere in the whitepaper. An extension might ship with all of the tests it needs, while not being built using the TDD procedure. Is that wrong? No, TDD is not a neccessity. But if you have become adjusted to the idea that all of your code should be tested, it simply makes more sense to embrace TDD.

Testing all of the code? I'm not entirely convinced (but hey, I'm not a TDD guru). I don't believe in 100% code coverage. Mainly because some code (like defining a composer.json or module.xml) is so easy, while writing a test for it will makes little sense. Also, some coding parts might require multiple tests to claim optimal quality, while the number of 100% will not go up to 120%: A single pointless test is already enough to cover the original code. So code coverage might lead to a wrong belief of what testing should solve.

Fix what hurts

I personally embrace PDT (Pain Driven Tests), instead of TDD. Note, I just made up that word. Instead of writing tests for something that will never hurt you, it is better to spend more time on writing tests for the most vital parts of your code. That is, as long as you have not written tests for everything yet.

PDT makes more sense to beginners, instead of enforcing TDD right from the start. TDD is hard to begin with and definitely when it concerns legacy code. The thought of PDT is that you start with the most annoying thing and make sure it keeps working. Perhaps this leads to refactoring, but by adding tests, you can slowly start to guarantee that code changes will not lead to annoying bugs anymore.

Tests are important

The whitepaper of ExtDN points out that tests are important. Period. It is something that everyone understands. But it is vital for extensions to have proper tests, because otherwise Magento as a system will never become more stable. I hear the complaint frequently: Magento is unstable, there are too many bugs. True, there is always something wrong: It is software. But often, the bugs come to rise when there is no test yet, or when untested extensions are introduced. Tests are a must.

ExtDN whitepaper

The ExtDN whitepaper offers many other interesting points. I hope to be back soon with more coverage :)

Posted on February 6, 2019

About the author

Author Jisse Reitsma

Jisse Reitsma is the founder of Yireo, extension developer, developer trainer and 3x Magento Master. His passion is for technology and open source. And he loves talking as well.

Sponsor Yireo

Looking for a training in-house?

Let's get to it!

We schrijven niet te commerciële dingen, we richten ons op de technologie (waar we dol op zijn) en we komen regelmatig met innovatieve oplossingen. Via onze nieuwsbrief kun je op de hoogte blijven van al deze coolness. Inschrijven kost maar een paar seconden.

Do not miss out on what we say

This will be the most interesting spam you have ever read

We schrijven niet te commerciële dingen, we richten ons op de technologie (waar we dol op zijn) en we komen regelmatig met innovatieve oplossingen. Via onze nieuwsbrief kun je op de hoogte blijven van al deze coolness. Inschrijven kost maar een paar seconden.