ERP5 is used for many critical applications. Our customers relies on
it to run their every day business, and they can not accept having
regularly bugs coming again and again. Every software issue could have
important consequences, especially if you think about banking, areospace
applications and many others. Therefore Nexedi consider the quality as
one of it's top priorities and decided to use automated testing since
the early age of ERP5.
While the code of ERP5 is evolving, more and more unit and functional
tests are added. When issues are reported, we write the test and fix
the problem. Like this we make sure that the same issue is not going to
happens again. Also, when new features are done, tests are added to make
sure we will provide well working experience. We have both unit test
and functional tests. Unit test are used to test isolated software
component, while functional tests are used to verify scenarios more
closed to user experience.
We tried for years to keep the quantity of failures as low as possible.
While the size of ERP5 was growing, it started to be more and more time
consuming to track regressions. In particular, it's quite common that a
change in some part of the code generate a regression in another place
that seems unrelated without detailed analysis. And then it happened
that we had several errors, and it was difficult to see new ones. Therefore, after our switch to git, we introduced the rule
"contributions must not introduce ANY regression". So we started by
fixing test failures, we checked all random issues, and we started to
reject any code introducing failures. The idea is simply to check all
unit test before contributing changes to the central place. This can
easily be done thanks to our Testing Infrastructure. Thanks to this rule, about any revision of ERP5 could be considered
as stable. This is really a great success. With a quantity of test
growing, we have nearly 0 errors/failures all the time.
We are using what we call "ERP5 Test Nodes". It's some processes
installed on many different machines thanks to SlapOS cloud tools. We
define several list of tests to run, and ERP5 test nodes will look
regularly to several git repositories to detect new commit, then they
launch software constructions and finally tests are automatically run.
Theses days we are using about 60 CPU cores to run tests for our various
projects and for different versions.
You can find below the result of automatic test of ERP5 code.
Hopefully you are able to see many test results at 0 errors/failures for
several thousands of tests. Since we are humans and not perfect, It
might happens that a change introduce a regression. But in this case,
you could be sure that we will quickly look and solve it.