Testing and Code Review

Scott McMaster 徐思遠 (TSMC IT)

∞ NTU 1
 Dr. Scott McMaster, Sr. Technical Manager

Experience: Education:
• Nearly 30 years of experience in IT, consumer software, • Ph.D. and M.S. (Computer Science), U. of Maryland, USA
engineering management and cloud computing • M.S.E. (Software Engineering), Seattle University, USA
• Former adjunct professor of Computer Science and Software • B.S. (Mathematics), U. of Nebraska, USA
Engineering at the University of Washington and Seattle
University

1995– 2002 2005 – 2007 2009 – 2015 2017 – 2019 2021 -- 2022

Microsoft Lockheed Martin Google Grab Promoted.ai 2022 – Present

as Software Test
Engineering, Lead
as Software Engineer as Software Engineer as Senior Software as Founding Engineer TSMC
Engineering Manager

2002-2005 2007 -- 2009 2015 -- 2017 2019 -- 2021

University of Maryland Amazon.com Microsoft Twitter

as Graduate Student Researcher in Software as Software Engineer as Software Design Engineer as Software
Systems, Program Analysis, and Testing
Engineering Manager

∞ NTU 2
Agenda
• Unit Testing
▪ “What” and “Why” of Unit Testing
▪ How to Structure a Unit Test
▪ Some Specific Unit Testing Techniques
• Functional Testing
▪ What is Functional Testing, and Differences From Unit Testing
▪ Designing and Automating Functional Tests
▪ Functional Tests in the Agile Process
• Code Review
▪ Why Review Code?
▪ How to Conduct a Code Review
▪ What to Look For

∞ NTU 3
UNIT TESTING

∞ NTU 4
What Makes Users Happy?

• Tests?
▪ Not clear that more tests => less bugs.
▪ Not clear that less tests => more bugs.
• => Tests don’t make users happy!

Lack of bugs makes users happy!

∞ NTU 5
How Do We Build a Lack of Bugs?

• One approach:
▪ Write and deploy a bunch of code.
▪ Have the testers and/or users take a look.
▪ Go back and fix the bugs.
• Why not this?
▪ It’s expensive.
▪ It’s frustrating.
▪ It has an open-ended timeframe.

It’s better to not deploy bugs!

∞ NTU 6
How Do We Stop Bugs Before Deployment?

• We always create bugs when

programming, right?
▪ What shall we do?
• One approach:
▪ Build, integrate, and test
thoroughly on your local
development machine (or in an
integration environment) before
submitting code.
▪ If you’re good at this and/or your
change is simple, there’s a
respectable chance that you have
prevented all the bugs the users
might see.

∞ NTU 7
Bugs Stopped! We’re Done?

∞ NTU 8
Useful Software is Never Really “Done”

• In fact, it decays!
▪ Users need new features and changed business logic.
▪ Libraries need patches.
▪ The infrastructure is changing.
▪ The operating environment is changing.

You must maintain

your software!

∞ NTU 9
If You Touch It, It Will Break
• It’s Really Hard to safely make changes to software.
▪ Especially when you haven’t looked at that code in six months.
▪ Or somebody else wrote it.
• How do you get changed software into the hands of users without
introducing new bugs?

Automated tests!

∞ NTU 10
Where To Start Testing?

Scenario Tests

System Tests

Integration Tests

Unit Tests

∞ NTU 11
 You Have to Start Somewhere

Scenario Tests

System Tests

Integration Tests

The Egyptians
started here,
too Unit Tests

∞ NTU 12
Automated Unit Tests

• Test like a programmer!

• Upsides?
▪ Really, really easy.
▪ Fast.
▪ Immediately debuggable.
• Downsides?
▪ Can be artificial and miss real-
world conditions.
▪ Weak at testing component and
system interactions.
▪ Tell you very little about whether
your software meets user
requirements.

∞ NTU 13
Side Note: Unit Testing in the SDLC
• Unit testing isn’t really a “testing” activity
▪ It should not be part of your software testing estimates.
• Unit testing is a “coding” activity.
▪ It should be part of your software development estimates.

Saying you will “write

unit tests later” isn’t
really a valid
statement

∞ NTU 14
What Does a “Good” Unit Test Do?

1. Documents what you

tested.
2. Demonstrates how the
code works.
3. Runs quickly and reliably.
4. Passes if the code meets
business requirements.
5. Fails if the code does not
meet business
requirements.

∞ NTU 15
How Does a “Good” Unit Test Do It?

• Whitebox (understands the

code internals, not just
external behavior).
• Doesn’t make remote calls
(databases or services).
• Doesn’t pollute the local file
system.
• Provides a clear report of
results.
• Doesn’t have dependencies on
other tests.

∞ NTU 16
Let’s Look at Some Unit Tests!

∞ NTU 17
 Here’s a Class

We should
definitely test this

Testing these is
debatable.

∞ NTU 18
Here’s a Test

Three observations to
follow…

∞ NTU 19
Observation 1: The Test Passes and is Fast!

∞ NTU 20
Observation 2: The Test Gets 100% Code Coverage!

∞ NTU 21
Observation 3: The Code We’re Testing is Spectacularly
Broken!

∞ NTU 22
Aside on Code Coverage

• Code coverage is a tool to show you

where you (might) need to add new unit
tests.
▪ Based on the costs and benefits of
“hitting” the uncovered statements.
▪ Some things like tests for error
handlers for catastrophic
conditions might not be
worthwhile.
• High code coverage is NOT a guarantee
of quality code or quality tests.
▪ You are not automatically “done”
when you hit high coverage.

∞ NTU 23
Better Test

∞ NTU 24
Better Result

∞ NTU 25
Unit Test Structure

All three should be present in each

unit test

∞ NTU 26
Any Lingering Problems?

We didn’t test
the order date
value

∞ NTU 27
Idea 1: Use a Regular Expression

• It’s ugly (the full regex is >200 characters).

• It doesn’t validate that we use the correct date.

∞ NTU 28
Idea 2: Use the Date From the Order

• Doesn’t validate that the date is what was expected.

• Mirrors the implementation.
• => Unit Testing Rule: Don’t duplicate the implementation in the test.

∞ NTU 29
Idea 3: Take Control of the Date

• What if the test itself knew

the date before it used it?
▪ Similar to how we know
the customer id and
order id.
• Then we could directly
assert the Order got created
with that date.
• But…can we really control
time?

∞ NTU 30
Side Quest: Software Design

∞ NTU 31
Testability

• Unit testing is a design

activity as much as a testing
activity.
• Testability == enabling code
for testing, usually through
better low-level design.

∞ NTU 32
How to Achieve Testability

• Lots of ways, but the biggest

one is to program with
interfaces.
▪ Interfaces enable test
doubles.
▪ Especially when combined
with Inversion of Control
(IoC).
▫ “Accept your
dependencies, don’t
create them”

∞ NTU 33
Test Doubles

• Test-time replacements for

library and service
integrations that aren’t easy to
test.
▪ Different types (mocks,
fakes, stubs)
• To use, you often have to
change your design
• But the design you end up
with often ends up being more
flexible and maintainable

∞ NTU 34
What Is There To Dislike With This Code?

• Current time is different every time the tests run.

• Unit Testing Guideline: Avoid non-deterministic operations in unit tests.

This code is not very “testable”

∞ NTU 35
Constructor Cautions

• Constructors are actually a little dangerous:

▪ Constructors should be trivial.
▫ Do assign fields to default values or from args.
▫ Don’t “new” objects in constructors.
▫ Don’t load from databases or files in constructors.
▫ Don’t do expensive calculations in constructors.
▪ These things all make the code less testable.

∞ NTU 36
Constructors Can Be Bad For Testability
• Let’s make our constructors trivial.
• And private!

Wait, what, how do we

create orders now?

∞ NTU 37
Creational Design Patterns

• Factories
• Builders

∞ NTU 38
Builder Example

• Static inner class

Note this
▪ Gets to use the trivial private
constructor
• Has setters for fields that the
client will use.
• It’s actually safer to use than a
constructor, too.
• And can reduce the number of
constructor overloads you have
to write.
• To use:

Note this

∞ NTU 39
I Thought We Were Discussing Unit Testing
• Now we can write a really good unit test for toString()

∞ NTU 40
Aside: You Should Unit Test the Builder, Too

At least if it’s not 100% auto-generated

∞ NTU 41
Aside 2: Better Ways to Handle the Clock

• Probably don’t want to have to create the

correct Clock each time when using this
class and builder.
• Design homework for you.
∞ NTU 42
My Language Doesn’t Have a “Clock”
• Build your own clock: 1) interface 2) real one 3) fake one

∞ NTU 43
Let’s Try Something Else – File Output

∞ NTU 44
First Try Unit Test
• How many problems do you see?

∞ NTU 45
Problem 1: Pollutes the Test Output
• By using a real logger – can make test output hard to read and debug
• Unit Testing Guideline: Don’t write to log files or the console in a unit
test.

∞ NTU 46
Fix 1: Use a Stub Logger

• Refactor the code • Create a “stub” Logger in the

“test” package

Side note: You can probably also

suppress output with test-specific (this is a long class but
log config, depending on your it’s 100% auto-
logging library.
generated)

∞ NTU 47
Aside: Fakes vs. Stubs

• Both are Test Doubles

• Stubs:
▪ Canned, “no-op” responses
▪ Using for Logger since I usually don’t care to test log messages
• Fakes:
▪ Some real-looking responses that are controllable for testability
▪ Using for the Clock because it’s critical to test business functionality

∞ NTU 48
Fix 1 Continued
• Update the test

∞ NTU 49
Problem 2: Pollutes the File System
• This test can fail with a false negative if run more than once.

∞ NTU 50
Fix 2: Use Temp Directories and Files
• You can try to clean up files after a test, but if you fail, the system will eventually clean up for
you.
• And no worries about conflicting file names.

∞ NTU 51
Where We’ve Been
• “What” and “Why” of Unit Testing
• Arrange -> Act -> Assert
• Testability and Test Doubles
▪ Fake
▪ Stub
• Constructors, Builders, and Inversion of Control
• Temp Files in Unit Tests

∞ NTU 52
Much More

• Mock object frameworks

• In-memory databases
• Parameterized tests
• Language-specific unit
testing tricks
• Nice IDE things
•…

∞ NTU 53
Unit Testing Wrap-Up

• Unit testing is largely a

software design activity.
▪ Write unit tests at the
same time you write the
code.
• Think about the testability of
your code.
• Code coverage is a means
to an end, not an end itself.

∞ NTU 54
FUNCTIONAL TESTING

∞ NTU 55
Functional Tests
• Test like the user!
▪ Black-box =>
▫ You can’t see the code.
▫ You do not assume anything about the code.
▫ You can only see externally observable actions.
• Why?
▪ More realistic.
▪ Can explain to (and even develop with) your PM and/or users.
▪ One or two such tests might provide solid assurance that everything works well
for the user.

∞ NTU 56
Behold The Testing Pyramid (Again)

Scenario Tests

Functional System Tests

Tests
Integration Tests

Unit Tests

∞ NTU 57
(Some) Types of Functional Tests
• Integration
▪ Multiple modules
• System
▪ Whole system put together on real (or realistic) infrastructure
• Scenario
▪ Whole system put together like a user would use it

For the rest of the talk, let’s mostly not

care which we mean when we say
“functional testing”

∞ NTU 58
Functional vs. End-to-End (Scenario) Testing
• Difference (if any) depends on how you define the scope of the
“system”.
• Observation 1:
▪ Since some of our systems have effects in the physical world, true end-to-end
testing is not always possible/appropriate to do on a regular basis.
• Observation 2:
▪ Because of Observation 1, defining the system boundaries for functional testing
is important.

∞ NTU 59
Unit Testing vs. Functional Testing

∞ NTU 60
Unit Testing vs. Functional Testing

Unit Testing Functional Testing

• Execution always automated • Execution may be automated or manual
• Reporting always automated • Reporting may be automated or manual
• Code is specification • Should have documented design
• Required for CI • Probably required for CD
• Scope of a single library, app, or service • Scope of multiple libraries, apps, and/or services
• No environment to set up • Requires complex environment
• New tests written at the same time as the code • New tests may lag the code, and automation may
• Shifted left even lag the release
• Sprint-planned as part of coding • Harder to shift left
• Relatively easy to “measure” • Sprint-planned independently
• Can be harder to “measure”

∞ NTU 61
Unit Testing vs. Functional Testing
Would you rather drive
after these are tested? Or this is tested?

∞ NTU 62
 Agile Testing Quadrants

Automated &
Manual Business-Facing Manual

Support Engineering
Exploratory
Functional

Critique Product
UAT
Prevent User Story Detect
Scenario
Bugs Bugs

Performance
Unit Load
Component Chaos
Security

Automated Technology-Facing Tools

∞ NTU 63
Start Functional Testing

Let’s
NotAutomate!
So Fast

∞ NTU 64
Role of Automation in Functional Testing

Automation is the last step in functional testing, not

the first step.

• Functional test automation is probably only appropriate after:

▪ The test is designed.
▪ The test is documented.
▪ The test is reviewed with PM and perhaps users.
▪ The test has been manually run and debugged successfully.
▪ The test is identified as high priority for regression testing.
▪ There is a clear ROI to automating the test.

∞ NTU 65
To Automate Functional Tests?
• Automated functional tests may require a significant investment to
create and maintain.
• Unless you release relatively frequently, the ROI may be low.
▪ Once a month might be worth it.
▪ Once a quarter may well not be.
• Depends heavily on the difficulty in automating.
• And this depends heavily on the specific system and its environment.

• => There is no single answer as to what % of functional tests you

should automate.

∞ NTU 66
Functional Test Automation ROI

Automation Cost = ($Tools + $Authoring + $Maintenance) +

(#Executions * $Automation Setup)

Manual Cost = #Executions * ($Manual Setup + $Manual Execution)

• Estimate #Executions and $Maintenance over some % of the lifetime of the system.
• Consider some less-tangible factors (time to execute, reliability of execution).
• Only automate if Manual Cost >> Automation Cost in the final calculation.

∞ NTU 67
Releasing With Less-Than-Fully-Automated Tests
• When performing any manual release testing, there should be:
▪ Documented test cases
▫ Excel, Jira, or (better yet) a test case management system
▪ Reporting:
▫ What was tested
▫ By whom
▫ Results
▪ Sign-off to meet one or more of the following requirements:
▫ Compliance
▫ Accountability
▫ Trust
▫ => Can be done via the issue tracker

∞ NTU 68
Functional Test Design

∞ NTU 69
Functional Test Case Design
• Unlike with unit tests, it is NOT sufficient to rely on automation code to
specify functional tests!
• => We need documented functional test case designs.
▪ Even in Agile / DevOps.
• Documentation usually follows a test case template.
▪ Expect many people are already familiar with this idea.
▪ Can use the behavior-driven design (BDD) format.
▫ Given / When / Then

∞ NTU 70
Functional Test Case Template

Title

Priority

ID

Description

Setup/Teardown

Steps

Expected Results

Include in Regression Tests?

Automated / Should Automate?

∞ NTU 71
Functional Testing Timeline
• Given a new feature:
1. Design new functional tests as part of user story development.
2. Code the feature (and unit tests).
3. Manually run the functional tests for the feature in an integration environment ASAP.
4. Release the feature to UAT.
5. Re-test the feature in the UAT environment.
6. Release to users.
• When to automate:
▪ Between 2 and 3?
▪ Between 3 and 5?
▪ After 5? Suggestion: Don’t block a release
▪ Never? pending an automated functional
test.

∞ NTU 72
Automate Functional Tests

∞ NTU 73
Functional Test Automation Options
• Scripting
▪ Generally considered the best currently-feasible approach ⭐
• Capture/Replay
▪ Not recommended ❌
• Model-based testing
▪ May or may not be directly automatable (usually only applies well to certain systems)
• Test-in-production
▪ Canary testing
▪ Blue/Green deployments
▪ Shadow traffic
▪ May run into a lot of process and technology constraints in our environments

∞ NTU 74
Functional Test Technology Observations
• Functional test automation tends to be very application/domain-
specific.
▪ Unlike unit testing.
▪ Web != API != Mobile != Vendor != Infra Automation != AI/ML Sys != …
▫ And I mean, radically !=
▪ => No single or right-or-wrong answer to automation technology choices.
• However:
▪ The most interesting problems with functional test automation are around quality
processes, not technical implementations 💡

∞ NTU 75
Functional Test Scripting Technology
• Can often use the same tech used in unit testing.
▪ xUnit, TestContainers, your IDE, CI/CD system
▪ API, service, and database simulation and virtualization where needed.
• Video recording / screenshots
• Fuzzy/visual verification tools.
• Shared environments and databases.
▪ Be careful with state management, setup and teardown.
• Can use a dedicated “test scripting language”.
▪ Typically, Python or JavaScript these days.

∞ NTU 76
Functional Testing Metrics
• % Automated (vs. Manual)
• Product Coverage
▪ Can use user stories and tasks.
▪ Or requirements.
▪ Can include non-functional requirements (performance, load, etc.)
▪ Count test cases per criterion and note that there can be a M:M relationship between test
cases and product criteria.
• Risk Coverage
▪ Enumerate the risks / things that can go wrong.
• Code Coverage?
▪ Fun fact: You can collect code coverage from functional testing (including manual
functional testing).

∞ NTU 77
Functional Testing in the SDLC

∞ NTU 78
Functional Testing in the Waterfall

Requirements

Design
Implementation
Testing

Deployment

Maintenance

∞ NTU 79
 Functional Testing in Agile

Deployment Planning

This does
not refer to
unit testing

Testing Design

Implementation
∞ NTU 80
Functional Testing in Waterfall vs. Agile
• The main difference is how often you perform the functional testing
process:
▪ Waterfall:
▫ Expectation is that the cycle is very long, so you can afford a “long” test phase.
▪ Agile:
▫ Expectation is that the cycle is short, and therefore each individual phase must be
short.
♦ Implies the “Testing” phase must proceed quickly.
♦ Number of tests you can run may be limited.

∞ NTU 81
Agile Functional Testing Challenge

How do I pack a lot

of functional tests
into a short agile
test phase?

∞ NTU 82
Let’s Test Agilely

∞ NTU 83
Agile Functional Testing Process
• Execute and report on tests with each release.
• Add regression tests when bugs are found in UAT or production.
• Opportunistically automate the highest-priority functional test cases.
• Consider cost-based and risk-based tradeoffs.

∞ NTU 84
Example Agile Testing Process

Sprint 1

Release 1
Story 1 Func Test 1

Story 2 Func Test 2

Story 3 Func Test 3

Realistically, these are

probably test suites
that include tests for
various conditions

Automated Coding Budget: Up to 5 Stories and Tests Per Sprint

Don’t Run Test Budget: Up to 5 Manual Tests Per Release

Constraint: Can’t write a story test in the same

Manual Run
sprint as the story
∞ NTU 85
Example Agile Testing Process

Sprint 1 Sprint 2

Release 1

Release 2
Story 1 Func Test 1 Story 4 Func Test 4

Story 2 Func Test 2 Story 5 Func Test 5

Story 3 Func Test 3 Story 6 Func Test 6

Story 7 Func Test 7

Skip Func Test

2 for Sprint 2
since it’s lower-
Automated risk Coding Budget: Up to 5 Stories and Tests Per Sprint

Don’t Run Test Budget: Up to 5 Manual Tests Per Release

Constraint: Can’t write a story test in the same

Manual Run
sprint as the story
∞ NTU 86
Example Agile Testing Process

Sprint 1 Sprint 2 Sprint 3

Release 1

Release 3
Release 2
Story 1 Func Test 1 Story 4 Func Test 4 Story 8 Func Test 8

Story 2 Func Test 2 Story 5 Func Test 5 Story 9 Func Test 9

Story 3 Func Test 3 Story 6 Func Test 6

Story 7 Func Test 7

Run Func Test

2 for Sprint 3
since we didn’t
Automated run it for Sprint Coding Budget: Up to 5 Stories and Tests Per Sprint
2

Don’t Run Test Budget: Up to 5 Manual Tests Per Release

Constraint: Can’t write a story test in the same

Manual Run
sprint as the story
∞ NTU 87
Example Agile Testing Process

Sprint 3 Sprint 4

Release 3

Release 4
Story 8 Func Test 8 Story 10 Func Test 10

Story 9 Func Test 9 Story 11 Func Test 11

Regr Test 1

Regression tests
BUG 1
are usually the top
automation priority

Automated Coding Budget: Up to 5 Stories and Tests Per Sprint

Don’t Run Test Budget: Up to 5 Manual Tests Per Release

Constraint: Can’t write a story test in the same

Manual Run
sprint as the story
∞ NTU 88
Functional Testing Wrap-Up
• Functional testing:
▪ Is still essential in Agile and DevOps.
▪ Is as much about processes as it is about technology.
▪ Is not always automated.
▪ Depends on making the right engineering tradeoffs.

∞ NTU 89
CODE REVIEWS

∞ NTU 90
Why Do Code Reviews?

• Educate developers.
▪ Onboard new engineers faster.
▪ Share new programming
practices and libraries.
▪ Works both ways (reviewer <->
author)
• Spread knowledge around the team.
▪ At least two engineers then
know how to debug each piece
of code.

∞ NTU 91
Why Do Code Reviews? (2)

• Promote consistent design

and coding practices.
▪ Enforce coding standards.
▪ Over time, everyone is in-
sync and reviews require
less time/comments.
• Get new perspectives on code
and coding.
▪ What’s clear to the author
may not be clear to the
reviewer.

∞ NTU 92
Why Do Code Reviews? (3)
• Prepare the code for future maintenance.
▪ Reduce complexity.
▪ Increase readability.
• Detect defects
▪ Find bugs by inspection.
▪ Cheaper to fix during review than after merge.

I put this
one last ☺

∞ NTU 93
Code Review Roles

• Author:
▪ The person writing the code
and requesting a review of a
merge request.
• Reviewer:
▪ One or more engineers
reviewing the merge request,
making comments, and
(ultimately) approving.
▪ May be “required” or
“optional”.

∞ NTU 94
Code Review Terminology

• How to start a code review?

▪ “Pull request” / “PR”
(GitHub)?
▪ “Merge request” / “MR”
(GitLab)?
▪ “Phab” (Phabricator)?

• I will try to use “Merge

Request” here.

∞ NTU 95
Code Review Prerequisites
• Before a code review is requested, the code must:
▪ Be formatted according to standards
▪ Pass all linter checks
▪ Pass all new and existing unit tests
▪ Pass all other continuous integration (CI) checks
• Select reviewer(s)
▪ Good practice is two reviewers when possible:
▫ One reviewer more experienced in the domain or codebase.
▫ One reviewer less experienced in the domain or codebase.

∞ NTU 96
Code Review: Author Perspective

• Keep your merge requests small!

▪ Small MRs get reviewed faster.
▪ It’s easier to find bugs in small reviews.
▪ “100 lines is usually a reasonable size”.
▫ Source: Google
(https://google.github.io/eng-
practices/review/developer/small-cls.html)
▫ Although that may be a little small. Maybe
“a few hundred” is a better guide.
▪ Smaller, more frequent merge requests are
better.
• Prepare the code properly before asking for review.
▪ Satisfy all the Code Review Prerequisites

∞ NTU 97
Code Review: Author Perspective (2)
• Include new/improved unit tests in the same merge request.
▪ Test size counts toward the overall review size (make your merge requests small).
• Write a clear merge request title and description.
▪ Add details to the merge request to help the reviewer.
▫ Link to issue?
▫ Link to design document?
▫ Additional comments and explanations?
▫ Consider speaking 1:1 if that will help.
▫ Consider making review comments on your own code (but also if that should really be
a source comment).

∞ NTU 98
Code Review: Author Perspective (3)
• Consider adding screenshots or video if the change has UI.

• Review your own code first.

▪ In the code review tool (e.g. GitLab, use the “draft” feature).
▪ Fix, refactor, and clarify anything you find ahead of time.

∞ NTU 99
Tips for Creating Small Merge Requests
• Remember each merge request should do one (and only one) thing.
• Use feature flags.
▪ Keep work not ready to launch behind flags and off.
▪ Extra benefit: Feature flags make production releases less risky.

• Leverage git strategies.

▪ Work different features on multiple development branches.
▪ Favor rebase over merge to pull latest changes into development branches.
▫ How? https://www.atlassian.com/git/tutorials/merging-vs-rebasing
▪ Use stash save work not yet ready to be part of the merge request.

∞ NTU 100
Code Review: Reviewer Perspective

• Before starting:
▪ Does the code satisfy the Code
Review Prerequisites?
▪ Do you understand the change
well enough to review?
▫ If not, ask for explanation.
▪ Are there any other reviewers
that should be added?
• Dedicate a block of time.
▪ Less effective to switch back
and forth between other tasks
while reviewing.

∞ NTU 101
Things to Look for in Code Reviews

• Coding style
▪ Should match the style guide for the
languages used
• Naming
▪ Functions/methods
▪ Variables
▪ Packages
▪ Files
▪ Classes
• Readability
▪ Control structures that are easy to
understand
▪ Minimize levels of nesting {}

∞ NTU 102
Things to Look for in Code Reviews (2)

• Repetitive code
▪ Introduce constants for hard-coded
strings and numbers.
▪ Refactor common code to helper
functions.
• Documentation quality
▪ “Just right” amount of comments.
▫ Prefer to simplify the code!
▪ Extra care for documentation of code
being reused by other teams.
• Performance
▪ Efficient use of data structures and
algorithms
▪ Minimize RPC/database calls

∞ NTU 103
Things to Look for in Code Reviews (3)

• Logging
▪ Levels
▪ No PII, passwords, tokens, etc.
▪ Useful messages with context.
• Dependencies
▪ Use of approved libraries and
frameworks
▪ Reusable code in other projects
▪ Impacts on projects that depend
on the reviewed code

∞ NTU 104
Things to Look for in Code Reviews (4)

• Use of design patterns

▪ And SOLID principles
(https://www.baeldung.com
/solid-principles).
• Security
▪ Input validation
▪ Injection (SQL, XSS) issues
▪ Data encoding
▪ Access controls

∞ NTU 105
Things to Look for in Code Reviews (5)
• Error handling
▪ Usually something other than simply logging
▪ Exceptions vs. error codes
• Language-specific issues
• Unit tests
▪ For new features and changes
▪ All “interesting” inputs are covered
▪ Assertions that validate that the code did what was expected
• Think about the overall architecture and design
▪ Easy to forget when you’re focused on individual lines of code.

∞ NTU 106
Reviewer FAQs at This Point

• Do I really have to remember all of

those things?
▪ No, use a checklist!
• Where do I get a checklist?
▪ There are lots of them available
online.
▪ https://github.com/mgreiler/awe
some-code-review-checklists
▪ You should customize along
with your team/project.
▪ Make it language-specific.

∞ NTU 107
Code Review Checklist (Example)

https://codereviewchecklist.com
∞ NTU 108
Social Aspects of Code Review

∞ NTU 109
Code Review Service Level Agreement

• Reviewer and Author should reply to

comments within a known period of
time.
▪ Create an agreement on your
team(s).
▪ Say, 24-48 hours.
▫ One business day is ideal for
same-time-zone.
• Why?
▪ Don’t get blocked (especially when
doing small merge requests).
▪ Can remember the review context
between iterations.

∞ NTU 110
Delivering Code Review Feedback

• Be polite
▪ Focus on the code and making the code better,
not on the author.
• Explain why
▪ Refer to style guide or best practice.
▪ Point out how the suggestion improves the
code and its long-term maintainability.
• Make optional suggestions.
▪ Some things are interesting to point out but not
worth changes.
▪ Possible alternate solutions.
• Include compliments.
▪ “This function is particularly clear, nice job.”

∞ NTU 111
Handling Disagreements
• Assume the style guide is correct.
• Reviewer:
▪ Remember that the author of the merge request probably knows the code better
than you.
• Author:
▪ If it’s not in the style guide and there are no other deciding factors, bias toward
implementing the reviewer’s request.
• Worst case:
▪ Ask the team, tech lead, or manager for an opinion.
▪ Should be very rare.

∞ NTU 112
Requests for Cleanup/Simplification

• In general, take care of all of

these before merging.
▪ DON’T leave a “TODO”
▪ Unless it’s an
emergency?
• Why?
▪ It’s unlikely you’ll ever go
back to the TODO
▫ Unless something
breaks

∞ NTU 113
Use the Tools

∞ NTU 114
Use the Tools Most Effectively (some lesser-known features)
• “Start a Review”
▪ Batches up a bunch of comments to be published together.
• Suggestions
▪ Reviewer can write code in the comment, author can one-click apply.
• Drafts
▪ Start a merge request in “draft” mode, mark as “ready for review” later.
• See history / updates of the merge request
▪ Rewind through branch history to see the previously reviewed state of the code
• Bot reviewers
▪ Linters that run in the pipeline and insert comments to the review

∞ NTU 115
Code Reviews Wrap-Up

• Save time in your day to do

code reviews.
• Start making comments.
▪ Consider using a
checklist.
• Ask for feedback on
reviews.
▪ As a reviewer as well as
an author.

∞ NTU 116
 Thank You!

Scott McMaster 徐思遠

mailto:[email protected]

Images from https://www.pexels.com

∞ NTU 117