CST438 - Week 5

CST438: Software Engineering – Week 5

We have reached the fifth week of the software engineering course. We are reading about Google's large test and its scope to ensure the system works overall. The book mentions several reasons why we need a larger test and why unit tests are insufficient, potentially leading to undiscovered errors. For example, when using mocks, we replace the real data, and mocks may not behave in the same way. Another issue is that mocks written by someone other than the engineer who wrote the code may not understand how it works. Bad, wrong, and untested configurations are sources of serious bugs at Google. Besides configuration changes, faster than the code itself, causing a mismatch that breaks functions. Unit tests aren't designed to run under simulated real-world traffic that could be high and exceed the code's performance capacity. Therefore, large tests are needed to cover the unit test gaps and catch unexpected behavior.

Although large tests were introduced to Google before unit tests in products like AdWords, Search, and Gmail, unit tests later became the focus. The workflow of a large test involves obtaining the SUT for the system under test, seeding the data, interacting with the system under test, and reviewing the results. In some cases, complex SUT large tests are simulated in the full production environment to yield high fidelity. It is essential to balance the size of the large test by selecting an SUT that satisfies test reliability, the cost associated with running infrastructure, and the speed of the test.

When working with large tests, the system under the test requires seeded data to initialize the test stage, along with test traffic generated by the test when data is sent. Examples of seeded data include domain data, baseline data that resembles activities between uses, and complex data generated by APIs over time. Data could be sampled, copied from production, or manually created. Type of larger tests at Google: 

• Functional testing of one or more binaries 
• Browser and device testing 
• Performance, load, and stress testing 
• Deployment configuration testing 
• Exploratory testing 
• A/B diff (regression) testing 
• User acceptance testing (UAT) 
• Probers and canary analysis 
• Disaster recovery and chaos engineering 
• User evaluation

Authoring larger tests requires clear documentation and examples to standardize the procedure. Google runs larger tests in ways that are as familiar as possible to engineers; however, some tests need detailed instructional documentation. In the meantime, tests must run at an acceptable speed to encourage engineers to run tests more frequently. Larger tests must have clear owners listed, responsible for the test's health communications, and updates. Additionally, owners must be able to support the tests in the case of failures.

On another note, the team met to discuss the current iteration for the project. We had issue with merging conflicts last time, but we were able to determine the source of the issue and corrected it. I have been working on the frontend to implement the assignment view, assignment update, assignment addition, and the grading score recording. I definitely learned a lot about REST control and React interaction with backend, however, the syntax need more practice to master it. That’s my update this week.