Peer review can be a major contributor to code quality, but the practice is usually ill-defined and excludes some team members who can make a huge difference - those whose focus is testing.
The orthodox reasoning is that, if someone doesn't have development expertise, then they will not have anything to contribute to a code review. This is wrong on several levels. Software should be easy to read, logically structured, with clear, comprehensible names - and the people who are best placed to notice when it isn't are those who won't focus on syntax and coding style.
As well as contributing to the readability of the code, testers will gain early insight into areas of complexity or confusion, which is invaluable when making risk-based judgements about where additional testing is needed, whether automated, scripted, or exploratory.
In this interactive session, we'll explore how and why team members with testing expertise should participate in the peer-review of development commits. We'll dig into the positive impact this has on our products, our processes and our people. You'll leave with concrete next steps, including a structured description of an inclusive peer-review process and a modified Definition of Done.
The focus of peer reviews is frequently limited to code structure and conformance to coding standards not enforced by static inspection tools. The documentary value of the code (and specifically the unit tests) is frequently ignored, as is the need to communicate the extent of developer testing to their colleagues whose focus is on testing.
4. @sebrose http://cucumber.io
What is a review?
a formal assessment or examination
of something with the possibility or
intention of instituting change if
necessary
5. @sebrose http://cucumber.io
Formal
•done in accordance with rules of
convention or etiquette
•suitable for or constituting an
official or important situation or
occasion
•officially sanctioned or recognised
7. @sebrose http://cucumber.io
What is a code review?
a formal assessment or examination
of something with the possibility or
intention of instituting change if
necessary
8. @sebrose http://cucumber.io
What is a code review?
a formal assessment or examination
of source code with the possibility or
intention of instituting change if
necessary
10. @sebrose http://cucumber.io
What is a code review?
a formal assessment or examination
of a source code change with the
possibility or intention of instituting
change if necessary
11. @sebrose http://cucumber.io
What is a code review?
a formal assessment or examination
of a small source code change with
the possibility or intention of
instituting change if necessary
14. @sebrose http://cucumber.io
Today’s working definition
a formal assessment or
examination of a small source
code change
(by one or more of the author’s
peers) with the possibility or
intention of instituting change
if necessary
15. @sebrose http://cucumber.io
Why review?
A. Style, structure, conformity
B. Understandability
C. Performance efficiency
D. Bug prevention / detection
E. None of the above
The PRIMARY reason for carrying out a review is:
25. @sebrose http://cucumber.io
Which is best?
To ensure future
understandability, reviews
should be conducted
without the presence of the
author(s).
26. @sebrose http://cucumber.io
Tests as documentation
So if you want to go fast,
if you want to get done
quickly, if you want your
code to be easy to write,
make it easy to read.
Robert Martin
27. @sebrose http://cucumber.io
Tests as documentation
@Test
public void scale() {
Date now = new Date();
Calendar calBegin = Calendar.getInstance();
calBegin.setTime(now);
calBegin.add(Calendar.HOUR, -4);
Date begin = calBegin.getTime();
Period p = new Period(4);
long delta = p.getBegin().getTime() -
begin.getTime();
Assert.assertTrue(
p.getEnd().compareTo(now) >= 0);
logger.trace(delta);
Assert.assertTrue(delta < 10 && delta > -10);
Assert.assertEquals(
new Integer(4), new Integer(p.getScale()));
}
39. @sebrose http://cucumber.io
How were they different?
The test acts as
documentation of the
developer’s intent.
Non-developers canunderstand the test
names
43. @sebrose http://cucumber.io
Readable unit test names
• Gives visibility to non-developers
• Allow focus on risk
• Minimise duplication of effort
• Maximise time spent exploring