Skip to content

Book: SE@Google Ch 16: Testing Overview #29

@jonasongg

Description

@jonasongg

Book: SE@Google
Chapter 16: Testing Overview

Summary:
Writing automated tests is important, even an integral part of modern software development! It's dangerous and fragile to rely on manual testing, especially when failures can make it to production and at the speed of modern development where hundreds of lines of code or more can change a day. Automated tests also serve a collective benefit for the software development team, saving developers time that adds up over days and years of development. Good testing code can even serve as effective code documentation that reflects the actual functioning and intention of the code. Lastly, they make code reviews easier (which is something I didn't think about!), because it clearly communicates what the code is meant to do.

Next, the chapter went into the specifications of a test suite - specifically, test size and test scope. Google uses small, medium, and large to describe test size, which refer to how constrained the test ism For example, small tests only run on a single process or thread. Google says a majority of tests should be small tests which help reduce nondeterministic behaviour and improve speed. This is something I considered, especially with RepoSense, as I never stopped to think how tests should be constrained in this manner. The second specification for tests is test scope, which says how much code is being validated by a test. Something I found interesting is that all of RepoSense's front-end tests are end to end tests, which is classified as the largest scope. I wonder if our frontend behaviour could be more finely defined and tested if we used unit tests as well!

Lastly, the chapter talks about the Beyonce rule, which says if you liked it, you should've put a test on it, which I found humourously encapsulates what tests should strive to achieve. If a feature is important enough to have been added, then it should be adequately tested (maybe even more) to validate its behaviour!

There is an issue on RepoSense to use Jest for unit testing for our frontend. It could be useful to see how this could work for RepoSense and what benefits it could bring! After all, Google says most tests in a project should be of small scope, but this again depends on the project itself.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions