Week 5 CST438
Summarize in a few sentences what you have learned this week.
This week in CST 438, the most interesting new idea I learned from Software Engineering at Google was the distinction of hermeticity and fidelity in large tests. Before this chapter I never really thought through how test environments take into factor how much they're isolated or not, or how closely they should mirror production. From my past experience with just programming, I have only considered unit tests and whether or not certain aspects such as functions or modules of my code would even work in my own environment, but now I am starting to think more broadly about what it means to test a system as a whole with larger tests. The chapter goes over how larger tests are often non-hermetic, meaning that they can share resources, interact with other traffic, or even pick up interference from the environment around them. Additionally, it mentions different levels of hermeticity can affect the fidelity of the tests which is the reflection of real behaviour. It was interesting to see this idea of how hermeticity plays a role in the structure of larger tests.
A phase of structuring larger tests that the chapter in the book had mentioned was obtaining a System Under Test which was defined as "one or more separate processes with test code often in its own process". In this case, SUT is hermetic as it is isolated from interactions with other components outside of the test itself. High hermeticity often collides with the concept of fidelity which is how close the testing is to production. If a test is high hermeticity then it has low fidelity and vice versa where low hermeticity can have high fidelity such as in shared environments like staging or production where tests can conflict with other uses like shared resources and traffic, risking impacting end users. The book goes over the ways to manage the trade-off between hermeticity and fidelity by introducing balancing solutions such as reducing the scope with hermetic SUT, having cloud-isolated SUT, relying on record/replay proxies, and having smallest possible tests such as chaining smaller pairwise integration tests rather than relying on massive end-to-end tests. Overall, learning about hermeticity and fidelity helped me understand the intentional design behind the large tests at google and how the engineers balance reliability and maintainability.
This week in CST 438, the most interesting new idea I learned from Software Engineering at Google was the distinction of hermeticity and fidelity in large tests. Before this chapter I never really thought through how test environments take into factor how much they're isolated or not, or how closely they should mirror production. From my past experience with just programming, I have only considered unit tests and whether or not certain aspects such as functions or modules of my code would even work in my own environment, but now I am starting to think more broadly about what it means to test a system as a whole with larger tests. The chapter goes over how larger tests are often non-hermetic, meaning that they can share resources, interact with other traffic, or even pick up interference from the environment around them. Additionally, it mentions different levels of hermeticity can affect the fidelity of the tests which is the reflection of real behaviour. It was interesting to see this idea of how hermeticity plays a role in the structure of larger tests.
A phase of structuring larger tests that the chapter in the book had mentioned was obtaining a System Under Test which was defined as "one or more separate processes with test code often in its own process". In this case, SUT is hermetic as it is isolated from interactions with other components outside of the test itself. High hermeticity often collides with the concept of fidelity which is how close the testing is to production. If a test is high hermeticity then it has low fidelity and vice versa where low hermeticity can have high fidelity such as in shared environments like staging or production where tests can conflict with other uses like shared resources and traffic, risking impacting end users. The book goes over the ways to manage the trade-off between hermeticity and fidelity by introducing balancing solutions such as reducing the scope with hermetic SUT, having cloud-isolated SUT, relying on record/replay proxies, and having smallest possible tests such as chaining smaller pairwise integration tests rather than relying on massive end-to-end tests. Overall, learning about hermeticity and fidelity helped me understand the intentional design behind the large tests at google and how the engineers balance reliability and maintainability.
Comments
Post a Comment