[haiku-qa] Re: haiku qa discussions - is everyone already familiar with BDD?

  • From: Ryan Leavengood <leavengood@xxxxxxxxx>
  • To: haiku-qa@xxxxxxxxxxxxx
  • Date: Wed, 29 Aug 2012 12:01:46 -0400

On Tue, Aug 28, 2012 at 4:26 AM, James Goss <jjgoss@xxxxxxxxxxxxx> wrote:
>
> However, I think we should develop a test "language" for Haiku.  That is, if
> Haiku were a business process, for example, how would we talk about it?
>
> The attached article from the Microsoft MSDN site kind of gets at that
> question and BDD in general.

It is a decent article. I've done BDD in my Ruby on Rails working
using Cucumber in the past, but I haven't used it for a while.

I think the problem that BDD presents for Haiku is how to automate GUI
applications and verify results (though this is a general problem, not
just for BDD.) Though automating or emulating a web browser is a
pretty difficult problem and that has been solved pretty well these
days.

Haiku may have a small advantage compared to other systems because
BeOS designed in some amount of "automation" in their applications
because they can support a suite of messages which pretty much act
like an API. Many basic things "come for free", like moving or
resizing windows, getting window titles, getting a count of windows,
etc. And applications can add on more. For example you can send a
message to Tracker to move a file to the Trash.

My thought would be to have an initial bootstrap step where the tester
can make sure that the suites needed to perform the automated testing
for a given application work as expected. For example:

"We are going to attempt to move the window 20 pixels down and to the right."
[The code does this.]
"Did the window move? YES  NO"
[If YES clicked, move on]

This way if for some reason the applications suites were changed or
broken, we can find out early.

Since I am a Ruby guy, I would be happy with using Cucumber as the
feature runner. Then we would just need to build the infrastructure to
run applications with their suites or however else. So for example:

Feature: Open an image
  In order to view my images, I open them with ShowImage

Scenario: Double click an image in Tracker
  Given there is an image file "test.png" in "/boot/home"
  And ShowImage is not running
  When I double click that file with Tracker
  Then ShowImage should launch
  And 1 window should open with the title "test.png"
  And the window's size should be 400x300

I think I could make the above work right now without too much work.
Deeper tests could be more tricky though, like triggering menu items
and verifying results. For example image zooming in ShowImage. Though
it might just mean adding more suites which just makes the apps more
useful in automation, which isn't a bad thing.

-- 
Regards,
Ryan

Other related posts: