Executable specification/continuous delivery

[ben.biddington]

Hi fellows,

Just wondered what your thoughts are on employing automated acceptance
tests (AAT) for web applications, particularly "rich client" (if
that's the term du jour).

Anybody writing executable specifications with testers/customers? If
so, have you found plain language specifications useful, or a burden
that nobody ever reads?

What about CI? How unwieldy are your builds?

What're you using? Cucumber? Fit? Concordion?

And if you do have AAT in place, how then are you using your human
testers?

<bb />

[Y. Thong Kuah]

Hey Ben

With any acceptance test, IMO there should be unit tests for the developer's sanity.

Cucumber is mostly what I personally and us at YouDo use. 

I'm sure some have found the cucumber specs shareable with non-developers but I haven't encountered a case myself.

CI is mostly a matter of running all tests upon push. It's Ruby, so there's not much of a build phase.

Above all, go with what your team will use everyday, and adapt and learn :)

Cheers

Thong

<bb />

--
You received this message because you are subscribed to the Google Groups "WellRailed" group.
To post to this group, send email to wellr...@googlegroups.com.
To unsubscribe from this group, send email to wellrailed+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/wellrailed?hl=en.

--
Best regards,
Y. Thong Kuah

http://kuahyeow.com

[Jeremy Olliver]

We've just setup Jenkins as CI yesterday, though this isn't the first time we've used it, and it seems to be pretty good.

I'm not a fan of plain language specifications myself, though am finding on our current project that rspec syntax in combination with Capybara steps (no cucumber) is very readable. I don't think it's feasible to get a BA to write the acutal tests/specs personally, and if they only need to specify what you're testing, not write it themselves, then sitting down with a BA/tester and writing some specs then is a nice way to go.

<bb />

--
You received this message because you are subscribed to the Google Groups "WellRailed" group.
To post to this group, send email to wellr...@googlegroups.com.
To unsubscribe from this group, send email to wellrailed+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/wellrailed?hl=en.

--
Jeremy Olliver

[Henry Maddocks]

Nahum's been playing with Capybara for UAT type stuff. He hasn't got very far into it yet but it looks pretty nice so far.
The scripts look something like...

select 'UPS Three-Day Select - 75.30', :from => 'order_shipping_method'

click_button 'btnReview'

assert_equal '$847.18', find('#cost-Making').text

Henry

[Walter McGinnis]

On Feb 10, 2012, at 2:27 PM, Jeremy Olliver <jeremy....@gmail.com> wrote:

> We've just setup Jenkins as CI yesterday, though this isn't the first time we've used it, and it seems to be pretty good.
> I'm not a fan of plain language specifications myself, though am finding on our current project that rspec syntax in combination with Capybara steps (no cucumber) is very readable. I don't think it's feasible to get a BA to write the acutal tests/specs personally, and if they only need to specify what you're testing, not write it themselves, then sitting down with a BA/tester and writing some specs then is a nice way to go.

Here's more discussion about cutting out cucumber and using some helpers for more helpful output when using rspec with capybara:

http://blog.railsware.com/2012/01/08/capybara-with-givenwhenthen-steps-in-acceptance-testing/

Haven't tried it myself.

[Y. Thong Kuah]

I'll take the opposite tack and say that clicking buttons, etc might be closer to how one developer would think, but there is value in abstracting the steps out into something a user actually does. Aslak says it better:

http://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off

[ben.biddington]

Thanks everyone,

Great to hear so many people are test-driving outside in.

As far as executable specification go, I think it depends who is
reading/writing them. I have yet to see anyone read a cucumber
feature, so I am not very interested in that overhead without good
reason. Specification By Example swears by it though, so I keep an
open mind.

Certainly I don't think non-technical people (testers for example)
should be *automating* acceptance criteria as they'll never be able to
write them clean enough.

I guess what I really want to know is if it realistic to expect good
browser-driven AAT for large, javascript-based applications. Or are
the tests likely to be impractically slow and/or brittle? (Consider
that a full regression sweep by humans takes two weeks.)

What about helping testers with automation? Anyone had god experiences
with that? Perhaps that's a good intermediate step.

<bb />

On Feb 10, 3:03 pm, Walter McGinnis <walter.mcgin...@gmail.com> wrote:

> On Feb 10, 2012, at 2:27 PM, Jeremy Olliver <jeremy.olli...@gmail.com> wrote:
>
> > We've just setup Jenkins as CI yesterday, though this isn't the first time we've used it, and it seems to be pretty good.
> > I'm not a fan of plain language specifications myself, though am finding on our current project that rspec syntax in combination with Capybara steps (no cucumber) is very readable. I don't think it's feasible to get a BA to write the acutal tests/specs personally, and if they only need to specify what you're testing, not write it themselves, then sitting down with a BA/tester and writing some specs then is a nice way to go.
>
> Here's more discussion about cutting out cucumber and using some helpers for more helpful output when using rspec with capybara:
>

> http://blog.railsware.com/2012/01/08/capybara-with-givenwhenthen-step...

[Gordon Anderson]

hi

Capybara can also do screenshots with a bit of prodding which can be useful for documentation purposes (e.g. not having to rescreenshot everything when the design changes slightly).  Pass in a list of URLs to this script

https://gist.github.com/1225970

Cheers

Gordon