Re: [TDD] Testing Views - iOS
If your views are dumb then you are doing it right. This means the only thing you views will define is the mapping between the UI events of the view and the
logical events of the presenter and vice-versa. This means that the only way to test the View is by looking at the actual UI and making sure that the mapping is done correctly. This means that for the most part the View part is just an adapter ¨C it takes a
button click, or a menu choice, or a gesture, or a text (CLI), or voice instruction{IVR}, or a dial tone (DTMF), a function call (API), or an HTTP command (another type of API), or an email message (yet another type of UI), and converts them into a user event
¨C e.g., SEARCH(). In the other direction ¨C it takes a user interaction ¨C e.g., Show Search Result(), and turns it into the¡ªsetting of text into a text field, or a list into a list box, or a generated voice, or an email, or a function response, or an email
response, or ah HTTP reply, or whatever, depending on the type of interface your are implementing.
?
This means that the View is extremely simple, and that the Presenter (or Controller) has no idea what UI is. In fact, it defines its own ABSTRACT, domain specific,
UI which you mock to test the Presenter and implement for every UI.
?
Where this becomes interesting is under two circumstances:
1.??????
The UI has specific UI interaction that need to be tested ¨C i.e., when you¡¯re implementing specific UI widgets ¨C e.g., a List
box (Scrollable), or Drag and drop, in which case you¡¯ll find that the View can be further separated into its own MVP, but that this time the domain is not the user¡¯s domain but rather the UI domain. This will allow you to define abstract operations like ¡®Show
Scroll Bar¡¯ or ¡®Mouse Click¡¯, which you can mock.
2.??????
Internationalization ¨C And other Skin related attributes like colors, fonts, etc. These are obviously UI specific, hence not
meaningful to the Presenter, but should still be testable. If you want these to be fixed, you can just test them by inspection (automated of manual). If however you want to them to change (as in i18n or locale information) then these values come from the Model
in the UI MVP.
?
?
So -?
[ Model ] == [ Presenter ] == [ View]??
is the application view, where the only difficult thing to test is the view (need to test with real UI).
But, if you have an specific UI interactions it will really look like ¨C
[ Model ] == [ Presenter ] == [[ uiModel ] == [ uiPresenter ] == [ uiView ]]
?
Which gives you two new layers of mocking and easy testing, if you need them.
toggle quoted message
Show quoted text
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: Sunday, June 1, 2014 12:49 PM
To: testdrivendevelopment@...
Subject: Re: [TDD] Testing Views - iOS
?
?
?
?
On Fri, May 30, 2014 at 4:22 PM, Luther Baker
lutherbaker@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?
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.
I don't know anything about iOS programming, so what I say might be completely useless to you. ?Anyway I will try a suggestion:
Can you imagine to test drive not the view themselves, but the code that builds the view? ?If this was a web application, I may want to write something like
view.addParagraph("bar");
the view object contains methods that make calls to the display technology. ?In html that would be just
void addHeading(String content) {
? this.html += " " + content + "";
in iOS you would have calls to the iOS APIs in there. ?The view builders would know nothing of iOS and could be easily test-driven.
void addGrayedOutButton(String title)
method working, and you know that it works because you've seen it working once, you shouldn't need much more testing unless you change its body.
|
Re: [TDD] Testing Views - iOS
|
Re: [TDD] Testing Views - iOS
That's what I'm trying out. I use KIF just a little, and call methods that events would be calling. Assert that output in text fields is correct. No mocks. Stub out one method in a fake UIButton. C. Keith Ray twitter: @ckeithray
toggle quoted message
Show quoted text
?
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
|
Re: [TDD] 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
?
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 ()
?
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
|
Re: [TDD] Testing Views - iOS
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)
toggle quoted message
Show quoted text
-----Original Message-----
From: Luther Baker lutherbaker@... [testdrivendevelopment] [testdrivendevelopment@...]
Received: Saturday, 31 May 2014, 7:51AM
To: testdrivendevelopment@... [testdrivendevelopment@...]
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
|
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
?
Can¡¯t you just screen scrape the views, given that they are supposed to drive the screen?
?
?
?
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.
|
Re: [TDD] Testing Views - iOS
Can¡¯t you just screen scrape the views, given that they are supposed to drive the screen?
?
toggle quoted message
Show quoted text
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: Friday, May 30, 2014 6:23 PM
To: testdrivendevelopment@...
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.
|
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
|
Re: [TDD] Testing Searcher Object
All,
I'll 2nd what Tim said, with this addition:
Since this is a TDD forum (not a general testing forum) I'll assume you're asking how to determine what microtests to write in order to drive your code to completion.
One thing I recommend to people who are just trying out TDD for the first time is to trust your existing instincts, up to a point:? You already know what code needs writing to solve one of Tim's listed scenarios? STOP YOURSELF and ask "How would I test that?" What small step can you take independent of others, and how will you test (or justify) the existence of that code branch, subclass, method, or whatever?? When you pass in /this/, you should get /that/. Go ahead and figure out what code you are just itching to write, then work backwards from that point in the code, but don't write the solution code first.? First figure out how you would test it.
If the answer isn't simple, then you've bitten off too much behavior.? Try a smaller piece.
It may end up that a single object is responsible for a Search, but there's no restriction on your design that says it has to do all that work by itself.? Can you find some bit of the overall behavior which can be built independently?? nextResult.isUnique()? results.empty()? Can you then build upon that success, to create simple tests for broader behaviors?
Let me end by reassuring you:? If you can write the code, you can write the test.? First.
Enjoy!
Rob
Rob Myers
Principal Instructor & Coach, Agile Institute
Rob.Myers@...
Twitter: @agilecoach
http://www.agileInstitute.com/
Come learn TDD in Vegas! My promo code 14CBSCWRM61 gets you an additional $200 off Agile Development Conference West registration (you win before you've even reached the tables!) http://www.sqe.com/Registration/AgileDevWest/SelectConference.aspx?eventid=14CADPW&Type=Conf
Agile Institute¡¯s Essential Agile Engineering Practices now satisfies the 3-day technical requirement for the Scrum Alliance's Certified Scrum Developer curriculum.
|
Re: [TDD] Testing Searcher Object
Thanks everyone for the feedback.? Exactly what we needed for our conversation.
?
How many ways are there for it to go right?? I can see a null response, a single return, multiple returns. Can it get duplicates? What other results are "happy" paths?
How many ways are there for it to go wrong? An invalid search? A backend that isn't working? An invalid input? what? What else?
Remember, you're testing the SEARCHER OBJECT not every possible search, or the system behind it.
-- blog:
twitter: @eikonne
|
Re: [TDD] Testing Searcher Object
How many ways are there for it to go right?? I can see a null response, a single return, multiple returns. Can it get duplicates? What other results are "happy" paths?
How many ways are there for it to go wrong? An invalid search? A backend that isn't working? An invalid input? what? What else?
Remember, you're testing the SEARCHER OBJECT not every possible search, or the system behind it.
On Mon, May 26, 2014 at 10:16 AM, Eb amaeze@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
Hi -
We
were having a conversation about testing a "searcher" object.?
Basically, this object does a search based on the inputs passed into
it.? Do tests have to be written for every permutation of inputs for the
class to have been tested properly?
Thanks. -- blog:
twitter: @eikonne
-- Tim Ottinger, Sr. Consultant, Industrial Logic -------------------------------------
|
Re: [TDD] Testing Searcher Object
Eb, On 5/26/14, 11:16 AM, Eb amaeze@... [testdrivendevelopment] wrote:
Hi -
We were having a conversation about testing a "searcher" object.
Basically, this object does a search based on the inputs passed into
it. Do tests have to be written for every permutation of inputs for the
class to have been tested properly?
Remember, the point of TDD is more to drive the design than to "test properly." That said, I wouldn't ever expect to test all permutations of something with a lot of permutations. I would check each input separately. If you want to go further, you might look at pair-wise permutations, and perhaps one or two "complicated" searches for peace of mind. - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ----------------------------------------------------------------------
|
Re: [TDD] Testing Searcher Object
Can you give us an example of a search? Or a few examples?
?
toggle quoted message
Show quoted text
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: Monday, May 26, 2014 7:16 PM
To: testdrivendevelopment
Subject: [TDD] Testing Searcher Object
?
?
We were having a conversation about testing a "searcher" object.? Basically, this object does a search based on the inputs passed into it.? Do tests have to be written for every permutation of inputs for the class to have been tested properly?
Thanks.
--
|
Re: [TDD] Testing Searcher Object
Eikonne,
?
I¡¯d probably start like this (and then let the code take me):
-?????????
Set up a failing test which is an interesting combination of input categories
-?????????
To get that passing, for each category set up tests which get a hit if a search target is there, and no hit if a search target is not there.
-?????????
Some examples of multiple hits
-?????????
My first test is green yet?
?
I would not be trying for all combinations, but I¡¯d likely be looking for edge cases.
And wondering if categories can overlap.
?
John D.
?
toggle quoted message
Show quoted text
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 26 May 2014 17:16
To: testdrivendevelopment
Subject: [TDD] Testing Searcher Object
?
We were having a conversation about testing a "searcher" object.? Basically, this object does a search based on the inputs passed into it.? Do tests have to be written for every permutation of inputs for the class to have been tested properly?
Thanks.
--
|
Hi -
We
were having a conversation about testing a "searcher" object.?
Basically, this object does a search based on the inputs passed into
it.? Do tests have to be written for every permutation of inputs for the
class to have been tested properly?
Thanks. -- blog:
twitter: @eikonne
|
Re: [TDD] Unit testing in C++11
I haven't used or really looked at your framework ... yet ... but I did check it out a little on github.? I like your choice in fluency syntax.
Good! :)
2013/7/25 Joakim Karlsson <joakim@...>
> **
>
>
> Although there are an abundance of unit testing frameworks for C++ out
> there, I decided to learn some of the features available in C++11 by
> writing yet another one.
>
> At this point it's mostly for play and to scratch an itch. I wanted to
> bring the good parts of writing unit tests in other environments with a
> quick setup, readable tests, no hardwiring to a specific assertion
> framework, and ease of organizing test hierarchies so that setups for a
> context can be easily reused and augmented by sub contexts.
>
> Anyway, there's a lot of subjectivity here, but if you find this
> interesting please take a look and let me know what you think.
>
>
>
> / Joakim
>
> [Non-text portions of this message have been removed]
>
>
>
--
Osias, o Osias
[Non-text portions of this message have been removed]
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
? ?
<*> Your email settings:
? ? Individual Email | Traditional
<*> To change settings online go to:
? ?
? ? (Yahoo! ID required)
<*> To change settings via email:
? ? testdrivendevelopment-digest@...
? ? testdrivendevelopment-fullfeatured@...
<*> To unsubscribe from this group, send an email to:
? ? testdrivendevelopment-unsubscribe@...
<*> Your use of Yahoo! Groups is subject to:
? ?
|
Re: [TDD] Re: Open Source Project Survey
|
Re: Open Source Project Survey
Hi,
Mark - Keep up the fight, TDD needs some more high quality
studies. Not sure where my research may fit in but if something interesting
comes out of it I may send it your way :)
Steven - A good idea, I'd imagine it might turn out to be a
little tricky in practice - at least given my time constraints. A consideration
for another project though.
Cheers,
Keith.
|
Re: [TDD] Open Source Project Survey
If you have access to the repo history, then the existence of unit test code and when they were first checked in relative to when the code they test was first checked in should give a handle on how test driven the code was.
On Tue, Apr 15, 2014 at 4:55 PM, Keith Fogarty <fogarty_keith@...> wrote:
?
Thanks Mark. Keith's 'distribution of complexity' measurement approach looks interesting for sure. I wonder if it ever became a research paper - a quick check doesn't show anything. It'd be particularly useful if there was some formal identification of test-first, test-last and no-test.
Anyway, I'll ask. Thanks again for the info,
Keith.
On Tuesday, April 15, 2014 3:12 PM, Mark Levison <mark@...> wrote:
?
Contact Keith Braithewaite he reviewed a number of open source projects that were done test first, last, not at all. His conclusions are quite interesting.
Cheers Mark
On Mon, Apr 14, 2014 at 5:05 AM, Keith Fogarty <fogarty_keith@...> wrote:
?
Hi,
I was
hoping you may be able to help.
I'm
working on a MSc. thesis and am looking to identify Open Source Test-First and Test-Last
projects for a research experiment.
To this
end I was hoping that anyone who has contributed to a Java open source project
(and has some overall knowledge of the project) could fill out the attached
(short, 12 questions) survey for that project?
My
research will look at Design Pattern Usage in Test-First and Test-Last projects
and I will post a link here to my research when finished.
Also (as
far as I can see) it's been a little while since the last 'What projects are
Test-Driven?' request in this group - by way of updating this information I can
post the survey findings here (for java projects anyway). ?Of course if you prefer your project not be
identified there is a privacy option on the survey.
?
Thanks in
advance for your help,
Keith Fogarty.
Link to the survey:
|
| |
| |
Hi, I was hoping you may be able to help me. I'm currently working on an M.Sc. Thesis and require a number of Test-First and Test-Last subject projects as part o... |
| |
| Preview by Yahoo
| |
--
|
Mark Levison?| 1 (877) 248-8277 |??|??|?
Certified ScrumMaster Training:??|??|??|??|?
?|?
Proud Sponsor of??and? |
|
Re: [TDD] Open Source Project Survey
Keith - I've been chasing your namesake to publish a paper on InfoQ for 4yrs so I assume not. Perhaps you can take on his mantle. Here is an offer as you write your thesis if you happen to produce an article or two for normal (agile) humans I can find a forum for it on InfoQ.com. We don't pay well in $$, but do pay in notoriety.?
(If anyone not named Keith wishes to step into the breach with a technical paper showing the benefit (or pain) of TDD, UnitTests, .... - I will find a home for it.
Cheers Mark?
On Tue, Apr 15, 2014 at 7:55 PM, Keith Fogarty <fogarty_keith@...> wrote:
?
Thanks Mark. Keith's 'distribution of complexity' measurement approach looks interesting for sure. I wonder if it ever became a research paper - a quick check doesn't show anything. It'd be particularly useful if there was some formal identification of test-first, test-last and no-test.
Anyway, I'll ask. Thanks again for the info,
Keith.
On Tuesday, April 15, 2014 3:12 PM, Mark Levison <mark@...> wrote:
?
Contact Keith Braithewaite he reviewed a number of open source projects that were done test first, last, not at all. His conclusions are quite interesting.
Cheers Mark
On Mon, Apr 14, 2014 at 5:05 AM, Keith Fogarty <fogarty_keith@...> wrote:
?
Hi,
I was
hoping you may be able to help.
I'm
working on a MSc. thesis and am looking to identify Open Source Test-First and Test-Last
projects for a research experiment.
To this
end I was hoping that anyone who has contributed to a Java open source project
(and has some overall knowledge of the project) could fill out the attached
(short, 12 questions) survey for that project?
My
research will look at Design Pattern Usage in Test-First and Test-Last projects
and I will post a link here to my research when finished.
Also (as
far as I can see) it's been a little while since the last 'What projects are
Test-Driven?' request in this group - by way of updating this information I can
post the survey findings here (for java projects anyway). ?Of course if you prefer your project not be
identified there is a privacy option on the survey.
?
Thanks in
advance for your help,
Keith Fogarty.
Link to the survey:
|
| |
| |
Hi, I was hoping you may be able to help me. I'm currently working on an M.Sc. Thesis and require a number of Test-First and Test-Last subject projects as part o... |
| |
| Preview by Yahoo
| |
--
|
Mark Levison?| 1 (877) 248-8277 |??|??|?
Certified ScrumMaster Training:??|??|??|??|?
?|?
Proud Sponsor of??and? |
-- |
Mark Levison?| 1 (877) 248-8277 |??|??|?
Certified ScrumMaster Training:??|??|??|??|?
?|?
Proud Sponsor of??and? |
|
