New model for actions

[Bernardo Heynemann]

Hey guys,

The current model for implementing custom actions in pyccuracy is using python code with classes that inherit from Action.

This is all fine and dandy, but when you need an action that's used only once or you want business people to be able to write them it is hard to use the current model.

I was discussing with Guilherme Chapiewski these days on how we can remodel the current actions model and we came up with some ideas.

First one is to be able to specify actions in your tests, like:

Define
    I login as <user> with password <password>
As
    I go to Login Page
    And I fill "username" textbox with "<user>"

    And I fill "password" textbox with "<password>"
    And I click "login" button
    And I am at Dashboard Page

As a Pyccuracy User

I want to test the new action model
So that I can make sure Pyccuracy works


Scenario 1 - Checking that after logging in I end up in the dashboard page
Given

    I login as "bernardo" with password "pyccuracy"
When
    #The page has finished loading

Then
    I see "Dashboard - My App" title

We are hoping that this model would encourage people to write less python custom actions and thus leave the actions near to where they belong.

Guilherme pointed out, correctly, that leaving ALL the actions in the tests would make them cryptical, whic has been one of the things we've tried harder to avoid.

He suggested we allowed users to put these definitions of actions in .act files that live in the same folder as the tests (or are specified using the action_dir option).
That would allow for a combination of reusable actions and only-once actions.

What do you guys think?

Cheers,
Bernardo Heynemann
Developer @ globo.com

[Luciano Ramalho]

On Wed, Jul 14, 2010 at 11:30 PM, Bernardo Heynemann
<heyn...@gmail.com> wrote:
> I was discussing with Guilherme Chapiewski these days on how we can remodel
> the current actions model and we came up with some ideas.
>
> First one is to be able to specify actions in your tests, like:
>
> Define
> I login as <user> with password <password>
> As
> I go to Login Page
> And I fill "username" textbox with "<user>"
>
> And I fill "password" textbox with "<password>"
> And I click "login" button
> And I am at Dashboard Page
>

I like the idea very much.

I'd suggest that the action definition starts with "Define action"
instead of just "Define". I see two advantages: makes it more explicit
what is being defined, and leaves the door open for further stuff that
may be user defined.

Cheers,

Luciano

[Ricardo Bánffy]

How would this be implemented? Would it require a new parser?

On Wed, Jul 14, 2010 at 11:30 PM, Bernardo Heynemann
<heyn...@gmail.com> wrote:

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

--
Ricardo Bánffy
http://www.dieblinkenlights.com
http://twitter.com/rbanffy

[Bernardo Heynemann]

The current implementation scans the file linearly, thus it would not be very hard to implement this feature in the test files. Implementing this in new .act files would be even easier. Matching the actions inside the definition to pyccuracy actions would be made at run-time after the parameters had been replaced.

Cheers,
Bernardo Heynemann
Developer @ globo.com

2010/7/15 Ricardo Bánffy <rba...@gmail.com>

[Felipe Knorr Kuhn]

Hello, Bernardo,

The new idea sounds awesome!

Are you going to keep the old model too?

Most of the time, the applications I have to test are not so automation friendly (apps using JSF with semi-random ids), so I have to use XPath monsters like this one:

//*[contains(text(), 'TEAM MEMBERS')]/following::a[text()='(Include)']

In cases like this one (and there are worse, actually), I believe only the older model would be helpful.

When the system has unique ids all over, does not have crazy ajax components, javascript menu trees, etc, then the new model would be perfect.

To be honest, I haven't been able to use Pyccuracy on a daily basis yet because writing custom actions to locate the page elements was a pain. But I haven't checked out the code since version 1.2.7 I think, so I probably missed a LOT.

Regards,

FK

On Wed, Jul 14, 2010 at 11:30 PM, Bernardo Heynemann <heyn...@gmail.com> wrote:

--

[Bernardo Heynemann]

Hi Felipe,

I think we got things mixed here.

You are referring to registering elements in a page. I'm referring to actions.

When I say: "And I click "some" button" I mean that "some" is registered in the current page (Login Page).

We could think of ways to improve registering elements in the test as well.

Cheers,
Bernardo Heynemann
Developer @ globo.com

[Felipe Knorr Kuhn]

Bernardo,

I ended up mixing two different (but still related subjects as custom actions must be able to resolve custom/registered elements) questions, so let me try to clear things up :)

Have a look at this thread (which dates from the last time I tried to used Pyccuracy):

http://groups.google.com/group/pyccuracy/browse_thread/thread/e03b828a1967b433

In that thread, I was interested in a way to write a custom action to reset and restore the database before running my tests.

Perhaps I didn't understand the new custom actions model, but it seems like you can only use it as a shortcut to other actions (or a sequence of actions, rather).

So, using the same reset/restore database example, I would need to use the older model, which is why I asked if you are going to keep the older model too :)


Regards,

FK

[Bernardo Heynemann]

Yep, we'll DEFINITELY keep the other way of doing actions. Experience shows that most actions are just shortcuts into a sequence of other actions. The actions that ACTUALLY use python code (mess with database, reset cache and any other fancy code you'd like) will still be written in python.

Given that, what do you think?

Cheers,
Bernardo Heynemann
Developer @ globo.com

[Felipe Knorr Kuhn]

I was just worried about the python actions being dropped, everything makes sense and sounds perfectly fine now :)

Thanks,

FK