Commit a3f537adbb9a3049d929af68288a3bdbcbd75eb0
1 parent
d8f2396f
Exists in
master
and in
3 other branches
Improving Automated Tests section
Showing
1 changed file
with
8 additions
and
25 deletions
Show diff stats
ieeeSW/releaseEng3/IEEE_ThemeIssue_ReleaseEng_CD.md
| @@ -181,31 +181,14 @@ https://www.openhub.net/p/mailman | @@ -181,31 +181,14 @@ https://www.openhub.net/p/mailman | ||
| 181 | 181 | ||
| 182 | ### Automated Tests | 182 | ### Automated Tests |
| 183 | 183 | ||
| 184 | -<!--- | ||
| 185 | -No final do contexto, adicionar um parágrafo final falando que geramos o SPB de forma a integrar 5 sistemas e manter mais de 30 pacotes. | ||
| 186 | -Os 5 projetos são: Colab, Noosfero, Gitlab, MailMan, and Mezuro. | ||
| 187 | - | ||
| 188 | -The SPB portal is a system-of-systems with 5 integrated software projects. | ||
| 189 | - | ||
| 190 | -To do this, we leveraged our choice of Colab (www.github.com/colab) as the | ||
| 191 | -orchestrator in the SPB. Colab is a systems | ||
| 192 | -integration platform for web applications based on a plugin architecture. In | ||
| 193 | -SPB, we developed specific plugins | ||
| 194 | -for each portal software component, such as Gitlab (www.gitlab.com) and | ||
| 195 | -Noosfero (www.noosfero.org). | ||
| 196 | ---> | ||
| 197 | - | ||
| 198 | -The SPB portal is a system-of-systems, each | ||
| 199 | -of them had to be tested with its own test suite. This was not enough, | ||
| 200 | -however: we also had to test the platform as a whole. Given that the plugins | ||
| 201 | -also have their own test suites, these suites assume a double role as both | ||
| 202 | -plugin tests and as integration tests. | ||
| 203 | - | ||
| 204 | -Both unit and integration tests provided us the performance and security needed | ||
| 205 | -to guarantee the stability of components and the platform. If any test suite | ||
| 206 | -failed, by either a test error or coverage reduction below a certain threshold, | ||
| 207 | -the process stopped. Only when all tests passed, the pipeline proceeded to the | ||
| 208 | -step of release preparation. | 184 | +Each integrated system had to be tested with its own test suite. This was not |
| 185 | +enough, however: we also had to test the platform as a whole. Given that the | ||
| 186 | +plugins also have their own test suites, these suites assume a double role as | ||
| 187 | +both plugin tests and as integration tests. These tests provided us the | ||
| 188 | +performance and security needed to guarantee the stability of components and | ||
| 189 | +the platform. If any test suite failed, by either a test error or coverage | ||
| 190 | +reduction below a certain threshold, the process stopped. Only when all tests | ||
| 191 | +passed, the pipeline proceeded to the step of release preparation. | ||
| 209 | 192 | ||
| 210 | ### Preparing a New Release | 193 | ### Preparing a New Release |
| 211 | 194 |