Skip to content

Concepts

Concepts🔗

Why another test tool ?🔗

Chutney is an opinionated test tool based upon the practice of Specification by Example.

Chutney was inspired by Seb Rose blog post in which he revised the test pyramid according to test readability The Testing Iceberg

Chutney is not exactly what Seb Rose meant by using this metaphore.

But we envisioned a tool allowing multiple levels of readability, providing a single place for business people, testers and developers to co-create, share and execute acceptance tests.

Moreover, we needed to :

  • Promote and support Specification by Example across multiple teams and offices
  • Ease collaboration and shared understanding in a "not so agile" environment
  • Provide a single source of truth without hiding details in tests glue code
  • Ease the automation of thousands of manual tests without writing and maintaining specific code
  • Automate end-to-end tests of distributed software across secured networks, including hardware over telco networks

What is it not ?🔗

Chutney is not a replacement for tools like Cucumber, etc.

While having some overlap, they all fill different test aspect.

The key difference is the absence of glue and support code.

While we think that having glue code is cumbersome and adds unnecessary levels of indirection between the features and the system under test, especially for high level tests and distributed softwares.

We also do think that using Cucumber for low level testing is sometimes very handy and useful, thanks to the high level of expression provided by Gherkin (and this is part of the Testing Iceberg Seb Rose talked about).

Chutney is no silver-bullet, it is just a tool which promotes and supports one way of doing software testing.

As such, to benefit from it, we highly advise you to be proficient or to document yourself about Behaviour-Driven-Development (by Dan North), Specification by Example (by Gojko Adzic) and Living Documentation (by Cyrille Martraire). All of which, however you call it, define the same practices and share the same goals.

Global understanding of Test Driven Development and knowledge about Ubiquitous Language (from Domain Driven Design, by Eric Evans) is also valuable.