We explain which software testing mix we use for our online platforms and why we chose it.
In our last blogpost we highlighted the importance of software testing and explained the different types of software testing. When classifying the right mix of software testing, we mentioned that it depends on the type of project. So, a website needs a different mix than, say, a web application or online platform. Therefore, in the current blog post, we will go into more detail about the mix of tests we use for our self-developed software.
Why do we do software testing?
Tests are part of good software today. Therefore, it may seem somewhat superfluous that we go into extra detail here about why we use software tests. However, it is important that the advantages and especially our benefits are highlighted.
By using software testing, the following benefits can generally be reaped:
- Quality assurance
- Functional testing
- Improvement of UI & UX
- Automation
Since our software is continuously developed and enhanced, software tests are essential for the quality of our applications. They therefore bring us additional benefits:
- Tests prevent regressions, so there are fewer errors in new code in the future.
- Tests help to improve the scalability of applications.
- Tests ensure that the application still works after major updates.
- Tests ensure the quality, structure and resilience of the code, making future refactoring easier.
What is a good test anyway?
With all the advantages of software tests, the question arises as to how a good test is defined in the first place. We have defined this for us as follows:
A good test
- is resistant to refactoring. It still works, even if the code has been adapted. Only if there is a feature change, the test will not work anymore.
- runs fast and is fast to develop. The longer the time to develop, the smaller the chance that the test will be written at all, because too little value is generated with the test to justify the high effort.
- covers as much code as possible (Code Coverage). Code coverage is the number of lines of code that have been successfully validated as part of a test procedure.
- is accurate and tests relevant code. False positives and false negatives are undesirable and tests that test irrelevant portions of code should be avoided.
Based on these characteristics and guidelines, we try to develop the appropriate tests for each software project, so that we can always guarantee the maintenance and further development of the respective applications.
Tests at cloudtec
At cloudtec we mainly use three different types of tests:
Behat tests, feature or module tests and unit tests. Behat tests, also called UI tests, are used wherever the user interface needs to be tested. Behat tests are also used to test the JavaScript. They are slower than other tests because they simulate a browser, but the code coverage and resistance to refactoring are excellent. With Behat Tests, we map the workflows within an application - or a platform - and run different scenarios with test data. We also use the tests to monitor permission structures and ensure that resources and content are visible only to authorized users.
Feature tests are used to simulate the Symfony framework and test the classes accordingly. Here again, the resistance to refactoring is less good than with Behat tests, but they are written faster and offer the advantage of better structuring the code. Therefore, we mainly use this type of tests to test specific parts of the code, such as a command or a mail template. An example where a feature or module test is used: We have a listener that creates a history entry when a configured item is created, updated, etc. With Behat, we verify that this listener is called by checking in the UI to see if there is a new entry. With feature tests (or module tests), we go through every single possible combination of created and updated entries and make sure that the subscriber processes them all correctly. This also ensures that the listener is called when an entity is updated via a command, for example.
The third type of test, unit tests, we use when a piece of code is self-contained, i.e. does not access other interfaces or functions. They run fast and are easier to create than the other two test types. For example, we use them to test the functions that calculate the prices in our eShop bundle. This way we can make sure that the prices are displayed correctly.
Before introducing a new application, we also use smoke tests. We use these to check whether functions and services have been implemented as desired or planned. They help us to conclusively check the availability of the entire platform. To do this, we use so-called route smoke tests. Here the test checks every single available route and sees if a positive status code (200) is returned. Another place where we use smoke tests is in our intranet projects. Our intranet is modular. This means that it can be defined per project which modules are used. Our smoke tests ensure that all modules work when creating the intranet projects, even if they are deactivated.
Software Testing at cloudtec: This is what we offer
You get online platforms and software from us that work reliably. Therefore, it is even more important that the quality is right. With software testing, we ensure exactly that and achieve a high level of quality. In all our projects, we make a point of closely integrating our customers into the testing phase. Nobody knows the requirements better than they do.
Are you looking for solutions for software testing or are you interested in starting an exciting project with us? Then please feel free to contact us at Contact . Together we will find the right solution for you.