googletesting: January 2015

Testing on the Toilet: Change-Detector Tests Considered Harmful

Tuesday, January 27, 2015

by Alex Eagle

This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. While fixing the tests, you get a sense that you are wasting time by mechanically applying the same transformation to many tests.What does it look like to write tests mechanically?// Production code:
def abs(i: Int)
return (i < 0) ? i * -1 : i

// Test code:
for (line: String in File(prod_source).read_lines())
switch (line.number)
1: assert line.content equals def abs(i: Int)
2: assert line.content equals return (i < 0) ? i * -1 : iThat test is clearly not usefulA correct or incorrect program is equally likely to pass// Production code:
def process(w: Work)
firstPart.process(w)
secondPart.process(w)

// Test code:
part1 = mock(FirstPart)
part2 = mock(SecondPart)
w = Work()
Processor(part1, part2).process(w)
verify_in_order
was_called part1.process(w)
was_called part2.process(w)This is a change-detector testit breaks in response to any change to the production code, without verifying correct behaviorChange detectors provide negative value

Testing on the Toilet: Prefer Testing Public APIs Over Implementation-Detail Classes

Wednesday, January 14, 2015

by Andrew Trenk

This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. Does this class need to have tests? class UserInfoValidator {
public void validate(UserInfo info) {
if (info.getDateOfBirth().isInFuture()) { throw new ValidationException()); }
}
}what if its only user looks like this? public class UserInfoService {
private UserInfoValidator validator;
public void save(UserInfo info) {
validator.validate(info); // Throw an exception if the value is invalid.
writeToDatabase(info);
}
}it probably doesn’t need testsUserInfoServicethe class is an implementation detail, not a public APIA public API can be called by any number of usersYou want to make sure these are well-testedAn implementation-detail class exists only to support public APIsThese classes can sometimes be tested indirectlyTesting implementation-detail classes is still useful in many casesthey often don’t need to be tested in as much depth as a public API,UserInfoServiceUserInfonullnullUserInfoValidator.validateYou should also try to restrict the visibility of implementation-detail classes,Testing implementation-detail classes too often leads to a couple problemsCode is harder to maintain since you need to update tests more oftenIf you test a behavior only through an implementation-detail class, you may get false confidence in your codeYou also have to be more careful when refactoring

Testing Blog

Testing on the Toilet: Change-Detector Tests Considered Harmful

Testing on the Toilet: Prefer Testing Public APIs Over Implementation-Detail Classes

Labels

Archive

Feed

Company-wide

Products

Developers