Back in December in my The Continuing Saga of Continuous Integration blog post I wrote about how we reduced the Testsuite’s “27” layers of file system access down to 3 by moving the Docker container’s /tmp filesystem to be memory backed. That reduced the number of individual test failures by quite a bit but still
Let’s talk some more about testing, understanding the test framework for Asterisk, and building better tests. An exciting topic I know! In a previous post, we discussed how unit testing Asterisk worked. Here, though we’ll be talking a bit about the Asterisk Test Suite. The Asterisk Test Suite is a way to write automated, functional, “black-box”
Continuous integration isn’t something that many people in the Asterisk project think about but it is a critical part of the development of Asterisk. It provides assurances on changes that go in and allows us to find problems faster, usually before a release occurs. The first introduction someone may have to our continuous integration is
In the previous post, we: Picked out a bug to fix, ASTERISK-25179 Signed up for an Asterisk account, signed a CLA, and created our profile in Gerrit Cloned Asterisk from its Git repo, installed its dependencies, built and installed it Run the Asterisk unit tests After doing all that, we concluded that we’d be better
