Methods of maintaining different development environments for future bug fixing : strengths and weaknesses
Kuosmanen, Valtteri (2024-03-15)
Kuosmanen, Valtteri
V. Kuosmanen
15.03.2024
© 2024 Valtteri Kuosmanen. Ellei toisin mainita, uudelleenkäyttö on sallittu Creative Commons Attribution 4.0 International (CC-BY 4.0) -lisenssillä (https://creativecommons.org/licenses/by/4.0/). Uudelleenkäyttö on sallittua edellyttäen, että lähde mainitaan asianmukaisesti ja mahdolliset muutokset merkitään. Sellaisten osien käyttö tai jäljentäminen, jotka eivät ole tekijän tai tekijöiden omaisuutta, saattaa edellyttää lupaa suoraan asianomaisilta oikeudenhaltijoilta.
Julkaisun pysyvä osoite on
https://urn.fi/URN:NBN:fi:oulu-202403152252
https://urn.fi/URN:NBN:fi:oulu-202403152252
Tiivistelmä
Automated testing plays a crucial role in continuous integration. The use of automated test cases enables developers to merge their changes multiple times a day by ensuring that no functionality gets mistakenly harmed in the process. However, in a large software project with multiple test automation engineers, even small differences in working environments or overall testing methods can result in complications, such as missing dependencies or non-functioning hard-coded paths. Therefore, a software project would benefit from a solution which could combat these issues without greatly impacting the amount of time needed for tests runs or the existing everyday workflow of test automation engineers. In this thesis, a containerization-based testing environment setup solution is presented. The setup solution improves the pre-existing one by adding the option of executing the test suite through a streamlined script. In addition, this script enables the engineers to run the tests inside a container. These improvements enable the software engineers of the project to easily transition from running automated test suites locally to running these same test suites safely inside containers. In this way it can be ensured that factors outside of the test cases, the relevant components and the project’s predefined build environment have no effect on test runs. This makes it possible to save time that would otherwise be spent troubleshooting issues caused by differing development environments. The implementation is also designed in a way that enables an easy transition for test automation engineers accustomed to previous testing methods, as the implemented shell scripts enable the engineers to give Robot Framework commands in a way nearly identical to locally run tests. Using the implemented testing process also has no significant effect on the time taken to run a test suite after the initial setup process, which takes approximately 50 seconds.
Kokoelmat
- Avoin saatavuus [37744]