Re: Extending TDD to ATDD
- --- In email@example.com, John Goodsen <jgoodsen@...> wrote:
>I suspect it really comes down to where your bugs come from. For example, at Socialtext, we have a 'watch page' feature. You click a star that says "watch page", the star lights up, then you clicked the "watched pages" link, the page now appears in the link. Go back, unwatch, watched pages, page does *not* appear.
>with over 50% of your code in the GUI layers, the argument to not test thru
>the GUI becomes a cop out for writing and maintaining good acceptance
>tests... google "declarative vs imperative cucumber" for more on that...
>yes, I know I'm on the controversial side of that one...
That's not the kind of thing I want to test through the business logic layer.
Our /whole app/ is like that.
We have also had a fair amount of success with GUI automation with Selenium, but a lot of that is due to the nature of our product and development process. In general, I recommend exploratory testing the GUI and a few small, light, quick, build verification GUI-driving tests.
Meanwhile, on the Software-Testing Discussion list, Elisabeth Hendrickson is making a big deal about how ATDD is /Acceptance/ Test Driven Development - not "Automated Testing During Development", and Ken Pugh is pointing out that you can do ATDD without automation:
Might be something to consider here, as, well, as I am /certainly/ not picking up that vibe here.
Personal Blog: http://xndev.blogspot.com/
Test Community Blog: http://softwaretestpro.com/blog/
- On Mon, Mar 7, 2011 at 9:38 AM, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:Mark,Yes, agreed, except I did add that part about "testers and developers" coming together in a "natural meeting place" we sometimes call "service layer testing". I think this "natural meeting place" is a good way for teams to become more efficient and more cross functional(a la Scrum), which adds a whole new set of cost savings. The "natural meeting place" was speaking more to team dynamics than test efficiency.
> In these cases the tests often wind up describing a form of public API.I think I agree with everything here except "public". To me, "public" API implies that you are planning to let other teams use your API directly. IMO, much more thought has to be given to an API before one makes it "public."Hence my use of the word "form". It maybe a public API but you're giving people access to it. Example said search functions are written in C#, the application now exposes them as Objects/Methods. Other applications in the client's stack could make use of this API, however you couldn't because you will never have access to the process to speak to the API.
Mark Levison | Agile Pain Relief Consulting | Certified Scrum Trainer
Agile Editor @ InfoQ | Blog | Twitter | Office: (613) 862-2538
Recent Entries: Story Slicing How Small is Small Enough, Why use an Agile Coach