Testable
The Testable gem aims to be a micro-framework that will provide a semantic DSL to construct a fluent interface for test execution libraries.
This fluent interface promotes the idea of compressibility of your test logic, allowing for more factoring, more reuse, and less repetition. You can use Testable directly as an automated test library or you can use it with other tools such as RSpec, Cucumber, or anything else that allows you to delegate down to a different level of abstraction.
Installation
To get the latest stable release, add this line to your application's Gemfile:
gem 'testable'
To get the latest code:
gem 'testable', git: 'https://github.com/jeffnyman/testable'
After doing one of the above, execute the following command:
$ bundle
You can also install Testable just as you would any other gem:
$ gem install testable
Usage
Probably the best way to get a feel for the current state of the code is to look at the test scripts:
If you clone the repository, you can see this script in action by running the command rake script:standard or rake script:factory.
You'll see references to "Veilus" and a localhost URL. I'm using my own Veilus application. The localhost refers to using the Veilus repo locally.
More details will be forthcoming as the project evolves.
Implementation Ideas
I want to hide driver details (i.e., Selenium) as much as possible but still allow access to the full API. Ideally I'd like to avoid the low-level Selenium and use a wrapper around it while not inventing my own. Since both watir-webdriver and capybara delegate down to Selenium, it seems wise to use one of those. (Or maybe allow for both as Symbiont currently does.) An open question is whether I should proxy the driver library to my own implementation or not. Symbiont currently does exactly that, which is a very different model than page-object, which has to add an incredible amount of wasted code rather than just relying on delegation and a proxy pattern.
I don't want to presume a particular modeling structure, such as the use of page objects. That being said, most such modeling structures are really just classes that are being utilized in a certain way, which means I really want to model the more generic notion of an interface. An interface could, theoretically, be an application (screens), a site (pages), or an API (services). An interface would be a Screen class, a Page class, or a Service class. These then become screen objects, page objects or service objects. An open question is how those distinctions are purely conceptual versus have specific implementations.
Development
After checking out the repo, run bin/setup to install dependencies. Then, run bundle exec rake spec:all to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.
The default rake command will run all tests as well as a RuboCop analysis.
To install this gem onto your local machine, run bundle exec rake install.
Contributing
Bug reports and pull requests are welcome on GitHub at https://github.com/jeffnyman/testable. The testing ecosystem of Ruby is very large and this project is intended to be a welcoming arena for collaboration on yet another testing tool. As such, contributors are very much welcome but are expected to adhere to the Contributor Covenant code of conduct.
This gem follows semantic versioning.
To contribute to Testable:
- Fork the project.
- Create your feature branch. (
git checkout -b my-new-feature) - Commit your changes. (
git commit -am 'new feature') - Push the branch. (
git push origin my-new-feature) - Create a new pull request.
Author
License
Testable is distributed under the MIT license. See the LICENSE file for details.