CODEWITHSUNDEEP
objective-cxcodemacoscocoatesting
Adam
Adam

Reputation: 1172

How can I create end-to-end tests for Mac (Cocoa) applications?

I have been reading a lot about test-driven development and decided that I want to give it a go on a small project. For reference, I am currently reading 'Growing Object-Oriented Software, Guided by Tests'.

I understand how to unit test my application and how to unit test certain parts of the UI as well, but I am struggling to set up end-to-end tests. For example, testing that a certain path through my whole application produces the correct output (this is my basic understanding of an end-to-end test).

It's not necessary to simulate click events, but it is necessary to have some sort of connection to the UI.

Am I right in thinking that I need a combination of "Logic" tests (test without launching the app), "Application" tests (test with launching the app) and the asynchronous functionality of something like GHUnit to accomplish this?

EDIT:

After reading some of the answers below, it sounds like I'm looking for functional end-to-end testing, but I think I should give an example of a test as I imagine it.

  1. Start the application.
  2. Call the login function with a test users credentials. (Note: doesn't necessarily need UI automation).
  3. Verify a label on the window says "Logging In...".
  4. After successfully verifying the user, verify the label now says "Welcome, Adam!".

KIF sounds like it could work, as it has steps to check changes in UI elements and it looks like there is a Mac OSX branch also. I'm sure I could also write a small class which constantly polls the UI for changes I expect and times-out after a certain time, but I'm wondering if this the right way to go about it.

However, perhaps I am trying to take what I am reading in 'Growing Object-Oriented Software, Guided by Tests' and trying to apply it too literally to Cocoa.

Another UPDATE:

So I've been reading the advice so far, checked the various places linked to and started to implement something whilst still referencing the book. I think what I'm really trying to get at is the Test-Driven-Development part. What stood out most in said book, was that they described what they wanted to happen from a users perspective first with acceptance tests.

I realise that solid unit testing will be necessary as soon as I start writing methods, but I was keen to write some high-level acceptance tests first, using some of the UI. I have started to write my own application "driver" class, using some similar methods to the GHAsyncTestCase ideas to help me accomplish this. Does this sound correct/useful/necessary?

I really appreciate all the comments so far and they have definitely helped me work out in my own head what I'm trying to do and what various areas of testing there are. I will finish up this question soon, as it is getting rather large, so any final advice is welcome!

Upvotes: 15

Views: 1186

Answers (4)

craigb
craigb

Reputation: 16907

I think the key thing that I got from "Growing Object Orientated Software" was to decouple as much as possible from the UI. Without code to look at it's harder to give suggestions but with your revision I'd think that separating the "verify a label says.." bit from the UI. What is setting this message, and can you just test for that event?

The more you can decouple from the UI the more you can unit-test (quicker and easier) rather than integrating other frameworks or drivers of UI elements.

Upvotes: 3

craigb
craigb

Reputation: 16907

You might be interested in Square's KIF framework: http://corner.squareup.com/2011/07/ios-integration-testing.html

It looks really cool for integration/UI testing.

Upvotes: 1

MoFlo
MoFlo

Reputation: 559

Based on your response to @Norman, I guess you're looking for recommendations that span both functional end-to-end as well as UI-based end-to-end but perhaps a UI automation framework might change your mind? Something intrusive like FoneMonkey might be helpful: http://www.gorillalogic.com/fonemonkey

If that doesn't work for you, I'd be interested in knowing why & what "gap" you perceive in such UI driven tests versus code-based functional testing?

Upvotes: 0

Norman
Norman

Reputation: 453

I believe you can use the Accessibility features to script the UI. I'd check the WWDC 2011 videos for one entitled "Design Patterns to Simplify Mac Accessibility". They did something similar in 2010.

Upvotes: 0

Related Questions