Tortilla¶ ↑

Tortilla is a wrapper around Cucumber and TestLink (using test_linker), used for easier automation of testruns using both. It is based on a purely script-based wrapper which is being refactored into an OO solution.

As such, Tortilla is very early stage and not for production use.

Common Usage¶ ↑

Requirements¶ ↑

• A Testlink installation, remote or local

• Cucumber binaries (‘cucumber’)

• SQlite3 (for saving testcases/results and configuration locally between testruns)

General flow¶ ↑

1. Set up testplan/build/cases in TestLink

2. Provide testplan/build to Tortilla

3. Tortilla pulls testcases (and/or stores them for later running)

4. Tortilla runs testcases using cucumber and parses fail/skip/success results which are saved

5. After user intervention, Tortilla uploads testcase execution results and any generated files (failure screenshots, ..) to TestLink

Current functionality (updated Nov. 6)¶ ↑

• Pulling tests and converting them to TestCase objects inside a TestCollection

• Saving a TestCollection with TestCase objects to a .torti file

• Starting a testrun from a pull, or from a saved torti file

• Flow if main() is started with config (Look for ‘nearby’ config files)

TODO Checklist/Wishlist¶ ↑

• Filepicker-type mechanic for config picking rather than having to give full path

• Add tests

• Add binaries

• Add option/way of allowing some other binary and test setup to be used other than matching prefixes (eg: someone using a different framework than cucumber features)

• Mailer module

• Define public/private methods for API usage

• Result parsing

KNOWN ISSUES/To check¶ ↑

• Builds are not saved properly to a tortilla file… We can:

1) Ask build at startup? (More intensive, maybe not as obv...)
2) Save build in .torti file (Easiest, most obvious)

Contributing to Tortilla¶ ↑

• Check out the latest master to make sure the feature hasn’t been implemented or the bug hasn’t been fixed yet

• Check out the issue tracker to make sure someone already hasn’t requested it and/or contributed it

• Fork the project

• Start a feature/bugfix branch

• Commit and push until you are happy with your contribution

• Make sure to add tests for it. This is important so I don’t break it in a future version unintentionally.

• Please try not to mess with the Rakefile, version, or history. If you want to have your own version, or is otherwise necessary, that is fine, but please isolate to its own commit so I can cherry-pick around it.

Copyright¶ ↑

Copyright © 2012 Bart Menu. See LICENSE.txt for further details.