Re: Testing Views - iOS

This sounds interesting. I didn't think a unit test (ala XCTest) for a
specific view would actually fire up the view - but is that what you're
thinking I should dig into - and then, assigning values to the child "tag"
properties and then proceed to simulate some interaction? Tap a button to
see some text get disabled?


Hmmmm ... I'm really curious now.


Thanks,
-Luther






On Sat, May 31, 2014 at 11:05 PM, Amir Kolsky [email protected]

[testdrivendevelopment] <[email protected]> wrote:


>
>
> You do not need to know pixels. If you know the IDs you can access the
> widgets. This is still a unit test.
>
> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>
>
> -----Original Message-----
> *From:* Luther Baker [email protected] [testdrivendevelopment] [
> [email protected]]
> *Received:* Saturday, 31 May 2014, 7:51AM
> *To:* [email protected] [
> [email protected]]
> *Subject:* Re: [TDD] Testing Views - iOS
>
>
>
>  Screenscrape? In iOS?
>
> I generally don't position things explicitly via pixels anymore - not with
> Autolayout so would be hard to tell exactly where something was to show up
> if I were writing the test first.
>
> I can write a UAT test that basically gets to that screen and can expect
> certain behavior -- but was looking for help regarding unit tests.
>
>  Thanks,
>  -Luther
>
>
>
> On Fri, May 30, 2014 at 10:11 AM, Amir Kolsky
> [email protected] [testdrivendevelopment] <
> [email protected]> wrote:
>
>>
>>
>>  Can’t you just screen scrape the views, given that they are supposed to
>> drive the screen?
>>
>>
>>
>> *From:* [email protected] [mailto:
>> [email protected]]

>> *Sent:* Friday, May 30, 2014 6:23 PM
>> *To:* [email protected]
>> *Subject:* [TDD] Testing Views - iOS
>>
>>
>>
>>
>>
>> I've essentially broken my GUI logic out into a rough MVP pattern and
>> while I find testing the Models and Presenters straightforward, I haven't
>> come up with a repeatable process to test drive the code in the Views.
>>
>>
>>

>> Granted, my views are dumb and have no real business logic - but for
>> instance, if something is disabled, I could test that certain fields are
>> set to 'readonly', or greyed out, etc.
>>
>>
>>
>> I generally use mocks and inject dependencies everywhere else in the app
>> - but that isn't as feasible in the views. Buttons, toggles and segemented
>> controls aren't something the parent view can just swap out, replace and
>> layout correctly. Injection doesn't feel right and so, because Views are so
>> 'self contained' - I find myself newing child components up inside of their
>> parent views and as such, I'm not sure how to TDD them without exposing
>> their internals somehow.
>>
>>
>>
>> Would great appreciate some suggestions.
>>
>>
>>
>> Thanks,
>>
>> -Luther
>>
>>
>>
>>
>     
>