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.

CST438 - Week 4

CST438: Software Engineering – Week 4

I find the book Software Engineering at Google a very good choice for this course, since it highlights the journey of Alphabet as one of the largest software development companies. The book goes beyond the short-lived academic coding assignments by exploring the formal stages of development and maintaining sustainable software.

The first chapter lays the fundamental distinction between software engineering and programming. The most interesting part of the book is the details regarding Google’s framework for its codebase and culture. For instance, Google strictly follows a process for code review on any changes. The process is simple, efficient, and effective in ensuring the integrity of the code before committing changes. The use of a scalable critique tool processes review requests in a timely manner in support of larger changes.

Additionally, Google has changed software testing by adopting automation, leading a major transformation in software engineering practices. In my opinion, this cultural shift is one of the most impactful changes Google has made to accelerate the development and deployment of technological innovations. These innovations have influenced modern DevOps culture, agile development, and large-scale engineering, allowing faster and more reliable releases. Many tech companies have now adopted similar models, increasing software release velocity and stability across the industry. It is worth noting that Google did not invent automated testing but refined it to support operations at scale. Finally, the authors share their extraordinary knowledge and experiences from years of working at Google, giving readers a deeper understanding of what it takes to build and scale software at a high level.

CST438 - Week 3

 

CST438: Software Engineering – Week 3

Git is a powerful platform that allows software engineers to manage source code and streamline the development process. By branching copies from the origin master, engineers can track changes and manage activities efficiently. This approach is especially effective for deploying tested code prior to merging it back into the main branch.

Branching strategies are commonly used to release software versions derived from a parent version. Depending on the software, this can result in either an update or an entirely new release. Developers also leverage Git to create isolated development environments in distributed Git for collaboration and version control.

For example, an engineer may pull the code from a remote Git repository to their local machine, make changes, and then push the updated code back to the remote. This workflow runs smoothly as long as no other developer has pushed a newer version in the meantime. If they have, the push will fail due to a mismatch. To avoid this, engineers are encouraged to pull from the remote regularly.

Merge conflicts can still occur, particularly when two or more developers modify the same line of code. Resolving these conflicts requires manual intervention—reviewing and editing the affected lines to determine which changes to keep.

Another key feature Git offers is the pull request. This enables team members to review each other’s code before it is merged into the master branch. Once the review is approved, the pull request is closed and the changes are merged.

 

CST438 - Week 2

 

CST438: Software Engineering – Week 2

Mocks are used to eliminate dependencies in testing, enabling fast, independent, repeatable, and timely unit tests. They are powerful tools that allow developers to avoid setting up full configurations for databases or external services when running JUnit tests. This lets developers focus on testing the behavior of specific functions without fully creating databases or external data sources for each test.

For example, if a test depends on other components to run first—such as initializing variables or creating fields—running the test in isolation can be difficult. JUnit mocking solves this by providing predefined responses from those dependent components, ensuring they don't interfere with the current test.