开云体育

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

[testdrivendevelopment] <testdrivendevelopment@...> wrote:

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.

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

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)

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

Can’t you just screen scrape the views, given that they are supposed to drive the screen? Sent: Friday, May 30, 2014 6:23 PM To: testdrivendevelopment@... Subject: [TDD] Testing Views -

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

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

Thanks everyone for the feedback. Exactly what we needed for our conversation. On Tue, May 27, 2014 at 12:29 PM, Tim

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

Eb, 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

Can you give us an example of a search? Or a few examples? Sent: Monday, May 26, 2014 7:16 PM To: testdrivendevelopment Subject: [TDD] Testing Searcher

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

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

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.

?Simple, you post here, I see it, I ask you to write an article. You sit down and write it in 2-3 days. You win everlasting fame :-) Seriously some fairly good gigs over the years cite articles I

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

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

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