We do have a plan to add workflow support in functional tests. The idea is to use phase binding. You can write different test cases for different stages, then you can have a place to define a workflow (which may include logic decision for which path to go in the workflow), either by a configuration file or Java annotations. What left is then how to bind your test case to a phase/stage. This idea is inspired by the Maven phase binding idea, where you can define different tasks and then bind them to the Maven life cycle. In our case, the phase/life cycle is not fixed. But to support this, we have to create our own test runner or extend some existing test runner.
I would suggest you create a flow control class to handle the flow logic. Also, you need to pass some temporal variables among different stages. You can use the Environment instance in 0.7.0 for this purpose. Don't know if this sounds doable for you. Thanks, Jian On Wed, Apr 21, 2010 at 6:40 AM, Jonathan Share <[email protected]> wrote: > Hi, > > Background: I'm writing tests for an online ordering system. In order > to perform a booking the user must go through 9 steps, some of these > steps are optional based upon the search criteria entered. The test > cases and parameters I need to fill the different stages are defined > in an excel file. I have now managed to implement the whole process, > however... > > Problem: I have ended up with having all of my ui for the whole > workflow and methods for interacting with it defined in one huge > class, with 520 lines in my defineUI() method and a further 1000 lines > of helper methods for interacting with the ui. I'm thinking of > breaking this down into one class per step in the workflow to make it > more manageable, however I'm a little uncertain of how I should handle > the instantiation of the model for the "next" screen. > > Question: Has anyone else implemented test cases of this type? How > have you managed splitting up of the code and transitioning from > screen to screen? > > As far as I can see at the moment there are two possible architectures > I can choose from: > > Solution 1: Performing an action that causes a transition to another > page returns the module for the next screen. > > class SearchPage extends DslContext { > def defineUI() { /* */ } > def searchReturnTrip(Date outboundDate, Date returnDate) { > // Fill in search form > // click search > def searchResultPage = new SearchResultPage() > searchResultPage.defineUI() > return searchResultPage > } > } > > class SearchResultPage extends DslContext { > def defineUI() { /* */ } > def chooseFirstResult() { /* */ } > } > > class TestCase { > void testMethod() { > def currentPage = new SearchPage() > currentPage.defineUI() > currentPage = currentPage.searchReturnTrip(new Date() + 1, new Date() + > 5) > currentPage = currentPage.chooseFirstResult() > } > } > > This seems like it will produce cleaner code in my main TestCase class > however it will get ugly int the *Page classes when handling cases of > the optional screens as you need to find out which screen you have > come to in order to determine which *Page class to instantiate. > > Solution 2: Always instanciate the expected *Page class in the TestCase; > > class SearchPage extends DslContext { > def defineUI() { /* */ } > def searchReturnTrip(Date outboundDate, Date returnDate) { > // Fill in search form > // click search > } > } > > class SearchResultPage extends DslContext { > def defineUI() { /* */ } > def chooseFirstResult() { /* */ } > } > > class TestCase { > void testMethod() { > def searchPage = new SearchPage() > searchPage.defineUI() > searchPage.searchReturnTrip(new Date() + 1, new Date() + 5) > > def resultPage = new SearchResultPage() > resultPage.defineUI() > resultPage.chooseFirstResult() > } > } > > This solution leaves the decision of which page should be next to the > TestCase (where we have enough information to make the decision of > what comes next) however I feel that littering the code with the > instantiation of new *Page objects will be less readable than the > first solution. > > Does anyone have any comments/guidance on these options that lie before me? > > Thanks in advance, > > Jonathan > > -- > You received this message because you are subscribed to the Google Groups > "tellurium-users" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<tellurium-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/tellurium-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "tellurium-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tellurium-users?hl=en.
