[jifty-devel] I'm designing a DSL for jifty's web testing...

[Edmund von der Burg]

> Have a look at the notes in the doc directory for some of the use cases
> nelson and I have been putting together.

Yes - that makes more sense. Rather than just adding new functionality
you are making it much more readable. This is an excellent thing.

A couple of comments though (nitpicking really). I read the file
declarative-test-design.

expect_url initially made me think that this url was to be found on
the page, rather than being the url of the page itself. Perhaps
something like 'expect_page_url' or 'page_url_is' would be clearer.
For checking that urls are on the page will you use something like
find_url '/foo/bar' ?



Each 'test' block is a separate test according to the comments, and if
anything inside a test block fails it is aborted. Does this mean that
the state is reset on exiting a test block (ie mech returns to the
page it was on when entering the test block)?

If the state is not reset then the order of blocks becomes important,
and a block failure could lead to other blocks failing - which is not
ideal.



    follow_link 'my folks' => 'My tasks' => 'Braindump';

Inspired - I am sold on this syntax just by seeing that.


Will there be a way to name the test blocks so that failure reporting
is clearer? perhaps something like:

test 'login and invite a friend' {
  ... tests.
}


One of the real strengths of this sort of testing is that it reads as
a natural language and so non-techs (i.e. customers) can make sense of
it. With this in mind I think that it might well be worth showing it
to some people who know nothing of WWW::Mech etc to see if it reads
clearly for them as well.

Excellent stuff.

Cheers,
  Edmund.


PS I gather that BTDT is your internal name for hiveminder. What does
it stand for? "bout time [I] did that" perhaps?