Essay (final submission): Automated tests for infrastructure code

[amarhod]

Essay: Automated tests for infrastructure code

The essay aims to present different ways of automating tests for infrastructure code when using tools such as Terraform and Kubernetes. Although the essay will not focus on any specific tool, rather give an general overview.

Members

Amar Hodzic (amarh@kth.se)
Github: amarhod
Niklas Wessman (nwessman@kth.se)
Github: nwessman

Submission

This is the final submission with the feedback implemented. See comment below by @nwessman for more details.

[nwessman]

Feedback Follow Up documentation

Submission before feedback
Feedback

We have made changes to our essay according to the feedback we got from @fbjorkman. Thank you for your feedback! We present the changes we have made below:

Note: The Bolded text is the feedback received. Solution: Is our solution to the feedback.

2 Background

I feel that there are some parts here that needs to be supported by some kind of source:

• In the first piece of section 2:
  “The appeal of using cloud providers, instead of investing in the hardware yourself, is the predominantly used pay-per-use model and the possibility to scale and provision resources as needed.”

Solution: Clarified the source of the first paragraph in section 2 by putting it in the end since the information in the whole paragraph was composed from the source.

• In 2.1:
  I think that what is written about consistency, reusability and transparency, either needs some kind of reference, or an explanation why each of them contributes to its benefits.

Solution: We fixed the position of the reference to make it more clear. Each point contains an explanation of their benefits.

• In 2.2:
  “By testing the code,confidence in it grows which can empower developers to dare make changes and add features.”

Solution: A new reference has been added to support the claim

• In 2.3:
  The first piece could also need some kind of reference, like for example:
  “If the software is not built from the start in a test-driven approach, introducing these concepts later in the development stages could lead to technical problems when trying to apply the automation tools to the project.”

Solution: Added reference and made it clearer what the reference is referring to.

3 Types of tests

• “On the one end, there is static analysis and unit testing which can give some confidence in the code on the other end... ”
  I would have written “At one end" and "at the other end”, but I think I would have personally used “On one hand” and “on the other hand”

Solution: Changed the phrasing to the last suggested proposal.

• Comment on Figure 1. Questions that arose when I first looked at the figure:
  What do the pyramids represent?
  What does it mean that the cross-sectional area is larger for each pyramid?
  One could make qualified guesses here, but I think a clarification about what the figure represents, why they look the way they do and the correlation between them would be nice here. Even though I think I understand the figure after looking at it and rereading the text a couple of times, I think that it would be good if you explained the figure a bit more.

Solution: We redraw the image and changed the perspective of the pyramid to make it face the reader so the labels could better fit in. Then we changed the labels and placed them in the same 3D space as the pyramid to make it more clear how the labels and the pyramid work together. Lastly, we changed the figure on the right to a legend instead to make that point more clear.

• In 3.2
  “The problem with unit testing in the context of IaC is that it is hard to test units without deploying the code since the code’s functionality often is to talk to the outside world.”
  What is the outside world in this piece? I felt that it was a bit unclear what that meant.

Solution: We changed the phrasing of "outside" to make it more clear what this intends.

• In 3.3
  “Integration tests pick up from where unit testing lefts off…”
  I would rewrite “lefts” to “left”.

Solution: Removed the 's'.

• No sources at all in section 3.4 End-to-end test, I feel like a lot of the content in that part is written as fact, but has no real support from any sources, so I think it would be appropriate to add some sources there.

Solution: A source has been added to support the example stated in the second paragraph as well as to the suggested incremental approach in the last paragraph.

4 Conclusion

• I wonder where the conclusion from this piece is drawn from?
  “ Instead of deploying it, running test, and then undeploy it each time, we can instead just redeploy each module that we have changed to save time.”
  I don’t really feel that I can connect that piece with what has been presented in the essay. This might be me that has missed something and if that is the case, maybe make that part a bit more clear.

Solution: The conclusion has been rephrased to draw the conclusion from the approaches and techniques discussed for the different types of tests.

References

• I am a bit unsure about putting the reference outside the punctuation as you have done in the following two cases:
  In 2.3:
  “...then it could lead to deploying bad code to production. [6]”
  In 3.2:
  “...each unit performs as expected. [8]”

Solution: We have moved both references inside the sentences.

• Link to [9] if you are interested to include it:
  https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:24765:ed-2:v1:en

Solution: Good reference! We have added it to our references.

[amarhod]

Hey @Deee92! We have now implemented the feedback that we got from @fbjorkman (thanks!) and think the essay is ready to be graded 🙈