googletesting

Android UI Automated Testing

Friday, March 20, 2015

by Mona El Mahdy Overview Robolectricgradle unit tests supportEspressotest support librariesStrategy 1: Using an End-To-End Test as a UI Test UI testend-to-end (E2E)

Very large and slow tests.

High flakiness rate due to timeouts and memory issues.

Hard to debug/investigate failures.

Authentication issues (ex: authentication from automated tests is very tricky).

Strategy 2: Hermetic UI Testing using Fake Serversserver hermetic testsblog

Strategy 3: Dependency Injection Design for Apps. Daggerinstrumentation testing

Strategy 4: Building Apps into Smaller Libraries

Conclusion

Don’t write E2E tests instead of UI tests. Instead write unit tests and integration tests beside the UI tests.

Hermetic tests are the way to go.

Use dependency injection while designing your app.

Build your application into small libraries/modules, and test each one in isolation. You can then have a few integration tests to verify integration between components is correct .

Componentized UI tests have proven to be much faster than E2E and 99%+ stable. Fast and stable tests have proven to drastically improve developer productivity.

The First Annual Testing on the Toilet Awards

Tuesday, February 3, 2015

By Andrew Trenk createdErik Kuefler:Test Behaviors, Not MethodsDon't Put Logic in TestsAlex Eagle:Change-Detector Tests Considered Harmful

TotT blog posts

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 on the Toilet: Truth: a fluent assertion framework

Friday, December 19, 2014

by Dori Reuveni and Kurt Alfred Kluever

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. As engineers, we spend most of our time reading existing code, rather than writing new code.Truth is an open source, fluent testing framework for Java designed to make your test assertions and failure messages more readable.assertEquals("March", monthMap.get(3)); // JUnit
assertThat(monthMap).containsEntry(3, "March"); // TruthAnother benefit of Truth over JUnit is the addition of useful default failure messagesImmutableSet<String> colors = ImmutableSet.of("red", "green", "blue", "yellow");
assertTrue(colors.contains("orange")); // JUnit
assertThat(colors).contains("orange"); // TruthJUnit will not provide a useful failure messageTruth will provide a clear and concise failure messageAssertionError: <[red, green, blue, yellow]> should have contained <orange>Truth already supports specialized assertions for most of the common JDK typesTruth is also user-extensible: you can easily write a Truth subject to make fluent assertions about your own custom typesTruth's goal is not to replace JUnit assertions, but to improve the readability of complex assertions and their failure messagesTo get started with Truth, check outhttp://google.github.io/truth/

GTAC 2014 Wrap-up

Thursday, December 4, 2014

by Anthony Vallone on behalf of the GTAC Committee GTAC 2014Google Kirkland officeArgentina, Australia, Canada, China, many European countries, India, Israel, Korea, New Zealand, Puerto Rico, Russia, Taiwan, and many US states

Adobe, American Express, Comcast, Dropbox, Facebook, FINRA, Google, HP, Medidata Solutions, Mozilla, Netflix, Orange, and University of Waterlooslides and video recordings

TwitterGoogle+

speakersGoogle Testing Blog

Protractor: Angular testing made easy

Sunday, November 30, 2014

By Hank Duan, Julie Ralph, and Arif Sukoco in Seattle protractortest.org

You don’t need to add waits or sleeps to your test. Protractor can communicate with your AngularJS app automatically and execute the next step in your test the moment the webpage finishes pending tasks, so you don’t have to worry about waiting for your test and webpage to sync.

It supports Angular-specific locator strategies (e.g., binding, model, repeater) as well as native WebDriver locator strategies (e.g., ID, CSS selector, XPath). This allows you to test Angular-specific elements without any setup effort on your part.

It is easy to set up page objects. Protractor does not execute WebDriver commands until an action is needed (e.g., get, sendKeys, click). This way you can set up page objects so tests can manipulate page elements without touching the HTML.

It uses Jasmine, the framework you use to write AngularJS unit tests, and Javascript, the same language you use to write AngularJS apps.

1) Set up environment npm install -g protractorwebdriver-manager update & webdriver-manager starthttp://localhost:44442) Write your test// It is a good idea to use page objects to modularize your testing logic
var angularHomepage = {
nameInput : element(by.model('yourName')),
greeting : element(by.binding('yourName')),
get : function() {
browser.get('index.html');
},
setName : function(name) {
this.nameInput.sendKeys(name);
}
};

// Here we are using the Jasmine test framework
// See http://jasmine.github.io/2.0/introduction.html for more details
describe('angularjs homepage', function() {
it('should greet the named user', function(){
angularHomepage.get();
angularHomepage.setName('Julie');
expect(angularHomepage.greeting.getText()).
toEqual('Hello Julie!');
});
});exports.config = {
seleniumAddress: 'http://localhost:4444/wd/hub',

specs: ['testFolder/*'],

multiCapabilities: [{
'browserName': 'chrome',
// browser-specific tests
specs: 'chromeTests/*'
}, {
'browserName': 'firefox',
// run tests in parallel
shardTestFiles: true
}],

baseUrl: 'http://www.angularjs.org',
};protractor conf.js1 test, 1 assertions, 0 failureshttp://angular.github.io/protractor/#/tutorial

Testing Blog

Android UI Automated Testing

The First Annual Testing on the Toilet Awards

Testing on the Toilet: Change-Detector Tests Considered Harmful

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

Testing on the Toilet: Truth: a fluent assertion framework

GTAC 2014 Wrap-up

Protractor: Angular testing made easy

Labels

Archive

Feed

Company-wide

Products

Developers