Why I write automated tests

Leave a comment

Why I write automated tests.

I write automated tests for a variety of reasons. For one they tell me when I break things. Secondly, having automated tests enables me to go fast. I can make changes with confidence. I am free to aggressively refactor my design. And I don’t stress about breaking the important stuff because I know the automated tests are there to back me up. They are like my shield and my armour.

But really, to me, automated tests are about leverage. They allow me to leverage myself in greater ways that wouldn’t be possible if they weren’t there. I can spend less time regression testing. More time adding new features, improving the testing while doing the one other kind of testing that’s really important – exploratory. These are things things the computer can’t do. Only I can.

So for me automated tests are about leverage. They give us a way to leverage ourselves and our teams further, while giving us all back the one thing we crave. Time.

Advertisements

The Way of the Web Tester

Leave a comment

Screen Shot 2016-09-15 at 5.45.37 AM.png

Hello everyone. A book I have been working on diligently for the last two years has finally hit the shelves. It’s called The Way of the Web Tester and it’s a book for anyone who wants to learn how to write automated tests for the web.

What’s in this book?

The book starts out by explaining what the three kinds of tests are that we typically see in web projects, along with some rules of them and guidance on where and when to use each.

We they spend a full two chapters at each level of something called the testing pyramid seeing how to add UI tests to legacy systems, how one can test web services, along with some rules of thumb around unit testing. That’s Part I.

Screen Shot 2016-09-15 at 6.25.50 AM.png

In Part II we build on the concepts outlined in the testing pyramid, but shift our focus to those skills specifically geared towards writing good tests.

First we look at some of the basics of programming, and show how by learning a few simple principles and practices we can dramatically increase the readability and maintainability of our automated tests.

We then look at some practices around test organization, and see how by simply grouping and organizing our tests in certain ways can make maintaining our tests so much easier.

And in the chapter on effective mocking, we look at some of the perils that come with this style of unit testing, and see how we can use mocks effectively while staying out of the swamp of mocking.

And we conclude with a section on the art of writing tests first. And see how beginning with the end in mind not only helps you test your systems, it can actually help you iterate on your design.

Who is this book for?

Screen Shot 2016-09-15 at 6.52.26 AM.png

If you are a tester who’s always wanted to get into test automation, this is the perfect book for taking that first step into a larger world.

If you are a developer, and you’d like to learn how to make your code even more robust, this book will show you how to move fast without breaking stuff.

And if you are team lead, looking better ways to get your testers and developers together, his is the Rosetta Stone you’ve been looking for.

Once your team has a common framework, language and understanding around automated testing, they will be able to better coordinate they’ll their efforts and write the best automated tests for your project.

So wait no further. Crush bugs. Move fast. And have fun. I hope you enjoy The Way of the Web Tester.

On sale now at all reputable book stores.

https://pragprog.com/book/jrtest/the-way-of-the-web-tester

https://www.amazon.com/Way-Web-Tester-Beginners-Automating/dp/1680501836

 

How to access a private method in objective-c for testing

2 Comments

Say you’ve got a private method

-(NSUInteger)stackCount {
    return [self.myStack count];
}
@end

And you would like access to it in your test.

- (void)testAddNumberToStack {
    Calculator *calc = [Calculator new];
    [calc pushOperand:1.0];
    XCTAssertEqual(1, calc.stackCount);
}

You could expose it publicly in your header, but that would means exposing our privates (something we prefer to avoid). One neat thing I didn’t appreciate Objective-C could do was simply re-create the interface you want for your object under test in your test class, exposing the method you want to call, and then calling it from there.

@interface Calculator (Tests)
-(NSUInteger)stackCount;
@end

@implementation CalculatorTest

- (void)testAddNumberToStack {
    Calculator *calc = [Calculator new];
    [calc pushOperand:1.0];
    XCTAssertEqual(1, calc.stackCount);
}
@end

It may seem like cheating a bit. But because Objective-c is just a method based language of communication, we can define the message we want to send the object, and just send it assuming that when the tests runs, the method is going to be there.

Thanks to Mikael for showing me this trick. Means I can keep certain methods private, yet get access to them when I want for testing. Var kul!

Complete source

Calculator.h

#import <Foundation/Foundation.h>

@interface Calculator : NSObject
// operations
-(double)result;
-(void)pushOperand:(double)number;
@end

Calculator.m

#import "Calculator.h"

@interface Calculator()
@property (nonatomic, strong) NSMutableArray *myStack;
@end

@implementation Calculator

-(NSMutableArray *)myStack {
    if (!_myStack) _myStack = [NSMutableArray new];
    return _myStack;
}

-(double) result {
    return 0;
}

-(NSUInteger)stackCount {
    return [self.myStack count];
}

-(void)pushOperand:(double)number {
    NSNumber *operandNumber = [NSNumber numberWithDouble:number];
    [self.myStack addObject:operandNumber];
}

@end

Calculatortest.m

#import <XCTest/XCTest.h>
#import "Calculator.h"

@interface CalculatorTest : XCTestCase
@end

@interface Calculator (Tests)
-(NSUInteger)stackCount;
@end

@implementation CalculatorTest

- (void)setUp {
    [super setUp];
}

- (void)testCreateEmptyStack {
    Calculator *calc = [Calculator new];
    XCTAssertEqual(0, calc.result);
}

- (void)testAddNumberToStack {
    Calculator *calc = [Calculator new];
    [calc pushOperand:1.0];
    XCTAssertEqual(0, calc.result);
    XCTAssertEqual(1, calc.stackCount);
}

@end

Test Automation (UIAutomation) example with XCode Instruments

14 Comments

UIAutomation is the library/tool Apple added in iOS SDK 4.0 to help with test automation on the iOS platform.

Scripts are written in JavaScript and executed through the Instruments Automation Instrument.

Here a quick walkthrough of how to record a script from your iPhone and play it back on your device.

Open Instruments

You open instruments through XCode -> Open Developer Tool -> Instruments.

Add Automation Instrument

There’s lots of instruments to choose from. The one we want is the ‘Automation’ instrument.

Add a script

Choose your target

Your target isn’t your device. It’s the device and your application.

Hit the record button

Record your script by hitting the ‘record’ button at the top or bottom of the tool and then click through your app.

Play it back

To see your script hit the funny looking Trace Log/Editor Log drop down and switch to scrip log view.

You should then see your recorded script.

You can play it back by clicking the ‘play’ button beside the record button at the bottom and you should see the same script played back against your phone. Output should look like this.

Save your script

This simple script doesn’t do too much, but it’s a start and if you want to save it and play it back later you can create a directory and story it in your app like this:

Much more

There’s a lot more we can do with UIAutomation. This is just a start and we’ve only scratched the surface.

But you can do a lot with this tool, and this is merely the first step.

Note: If your tests don’t run, make sure you aren’t connected and running your device from XCode. Can’t run both simultaneously so stop the XCode one then try running your tests again.

Links that help:

http://alexvollmer.com/posts/2010/07/03/working-with-uiautomation/

UIAutomation reference

%d bloggers like this: