Project

testable

0.0
No release in over 3 years
Low commit activity in last 3 years
Provides a semantic DSL to construct fluent interfaces for test execution logic.
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 2.0
>= 0
>= 12.3.3
~> 3.0

Runtime

~> 6.16
 Project Readme

Testable

Testable /ˈtestəb(ə)l/

adjective

able to be tested or tried.


Gem Version License

Yard Docs Inline docs

Testable is an automated test micro-framework that provides a thin wrapper around Watir. Testable is based on many ideas from tools like SitePrism and Watirsome, while also being a logical evolution of my own tool, Tapestry.

One of the core goals of Testable is to be a mediating influence between higher-level tests (acceptance criteria) and lower-level implementations of those tests. You can see some of the design principles for more details on what guided construction.

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 examples:

You'll see references to "Veilus" and a "localhost" in the script. I'm using my own Veilus application. As far as the localhost, you can use the Veilus repo to get a local copy to play around with.

Design Principles

An automated test framework provides a machine-executable abstraction around testing and encodes a set of guiding principles and heuristics for writing tests-as-code.

One of the obstacles to covering the gap between principles of testing and the practice of testing is the mechanics of writing tests. These mechanics are focused on abstractions. A lot of the practice of testing comes down to that: finding the right abstractions.

An automated test framework should be capable of consuming your preferred abstractions because ultimately the automation is simply a tool that supports testing, which means how the framework encourages tests to be expressed should have high fidelity with how human tests would be expressed. The execution of tests, whether automated or not, is often secondary to the design of those tests in the first place. Testable was designed around a couple of truisms:

  • When tests become automation:

    • We risk turning testing into a programming problem.
  • When tests become automation:

    • We risk the mechanisms overwhelming the meaning.

This is why Testable is designed as a micro-framework rather than a framework.

Testable is built around the the idea that automation should largely be small-footprint, low-fiction, and high-yield.

The code that a test-supporting micro-framework allows should be modular, promoting both high cohesion and low coupling, as well as promoting a single level of abstraction. These concepts together lead to lightweight design as well as support traits that make change affordable for tests.

That makes the automation code less expensive to maintain and easier to change. That, ultimately, has a positive impact on the cost of change but, more importantly, allows Testable to be fit within a cost of mistake model, where the goal is to get feedback as quickly as possible regarding when mistakes are made.

Some of the core principles of Testable's design are the following:

  • Embrace small code.
  • Abstraction encourages clarity.
  • No computation is too small to be put into a helper function.
  • No expression is too simple to be given a name.
  • Small code is more easily seen to be obviously correct.
  • Code that's more obviously correct can be more easily composed.

The above also led to some secondary, but no less important, principles of design:

  • Be willing to trade elegance of design for practicality of implementation.
  • Embrace brevity, but do not sacrifice readability. Concise, not terse.
  • Prefer elegance over efficiency where efficiency is less than critical.

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 test-supporting tool.

Everyone interacting in the Testable project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

The Testable gem follows semantic versioning.

To contribute to Testable:

  1. Fork the project.
  2. Create your feature branch. (git checkout -b my-new-feature)
  3. Commit your changes. (git commit -am 'new feature')
  4. Push the branch. (git push origin my-new-feature)
  5. Create a new pull request.

Author

License

Testable is distributed under the MIT license. See the LICENSE file for details.