https://github.com/axentro/spinach
BDD Style test runner
https://github.com/axentro/spinach
bdd crystal
Last synced: about 1 month ago
JSON representation
BDD Style test runner
- Host: GitHub
- URL: https://github.com/axentro/spinach
- Owner: Axentro
- License: mit
- Created: 2019-09-07T15:48:18.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2021-04-24T12:50:11.000Z (about 4 years ago)
- Last Synced: 2025-01-21T20:48:27.856Z (3 months ago)
- Topics: bdd, crystal
- Language: Crystal
- Homepage:
- Size: 1.09 MB
- Stars: 4
- Watchers: 3
- Forks: 0
- Open Issues: 4
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# spinach
BDD Style spec runner for Crystal. This project is fairly experimental and was written in a day so will be gradually improved over time. Please raise any feature requests or bugs.
## Installation
1. Add the dependency to your `shard.yml`:
```yaml
dependencies:
spinach:
github: sushichain/spinach
```
2. Run `shards install`
## Usage
```crystal
require "spinach"
```
The basic concept is that you write executable specifications in an HTML file that has a companion supporting crystal file. You then execute the crystal file and it will execute a spec and produce an augmented HTML file with the results.
You put your html file and supporting crystal file in the `spec` folder.
There are 3 directives:
* scenario
* table_scenario
* assert_equals
* set
* execute
* status
In your HTML you use these to write the specs. See below. See also the specs of this project for examples.
For each scenario the directives are located and then executed. The order in which directives are located is as follows:
1. table_scenario
2. scenario
3. set
4. execute
5. assert_equals
6. status
## Scenario
```html
If my name is Chuck Norris.
Then my username should be Chuck Norris2.
```
Each spec file must contain at least one scenario. A scenario is used to provide scope for the commands. When a spec runs
the variables used in the scenario are scoped to that specific scenario. So a scenario **MUST** be placed on a `Div` HTML element that
is a parent and then all the spec commands should go on HTML nodes that are children of this parent node. See the specs folder for
examples
## Table Scenario
```html
First name
Last name
Greeting
Message
Bob2
Bobbington
Hello Bob!
Your last name is Bobbington!
```
You add `spinach:table_scenario` to the table and then define your directives in the first row of the `thead`. You must use the `thead` and `tbody` elements. Also you must **NOT** put any directives on the first `tr` in the `thead` and instead only put directives on the `th` nodes. This is because each `tr` will be turned into a scenario and the appropriate directives dynamically added.
## Set Variable
```html
If my username is Chuck Norris.
Then the system should greet me with Hello Chuck Norris.
```
This will set the value `Chuck Norris` onto a variable called `#username` which you can use in a later assert_equals to assert a value.
## Assert Equals
```html
The greeting should be Hello World!.
```
This will assert the value returned by the method `get_greeting` with the supplied text: `Hello World!`
The return type of `get_greeting` **MUST** be a `String`
A second way to use assert_equals is when there is just a variable being asserted - either that has been set in the html or that is the result of an execute.
```html
If my name is Chuck Norris.
Then my username should be Chuck Norris.
```
## Execute
```html
The greeting Hello Bob!
And the message Your last name is Bobbington!
should be given to user Bob Bobbington
when he logs in.
```
This will store the result of the method `greeting_for` in a result `HashMap` which you can then use in later asserts.
When returning a result in an execute you **MUST** return a `HashMap`
## Implementation Status
```html
(expected_to_fail) The failed greeting should be Hello World!.
```
You can add the `status` directive to either the node with `spinach:scenario` to apply it to the whole scenario or you can add it to a specific assert_equals node.
## Running
To run a spec you can do the following:
NOTE - if you get a compiler crash while running then use the `--no-debug` flag when running and report the crash to the Crystal devs. Depending on what you put in the mapping Proc might cause the compiler to crash.
e.g `crystal run --no-debug spec/*.cr` or `crystal run spec/individual_file.cr`
but in general:
`crystal run spec/*.cr` or `crystal run spec/individual_file.cr`
if you want to put your specs somewhere else you can also do this:
`crystal run spec/spinach/*.cr -- -l "spec/spinach"`
There is a basic command line report:
* a green dot is passed
* a red F is failed
* a green F is failed but expected to fail
* a yellow I is ignored
* a blue P is pending
## Writing Specs
In the `spec` folder of your project you write 2 files:
1. assert_something.cr
2. assert_something.html
The names of the files must be the same. Also the name of the class in the crystal file must be the camel case equivalent of the file name. e.g. assert_something.cr must have a class called `AssertSomething`
here is an example of the files:
```crystal
class AssertEquals < SpinachTestCase
@[Spinach]
def get_greeting(args)
"Hello World!"
end
end
```
You must extend from `SpinachTestCase`. You must also annotate any methods that will be used by the spec from the html file. This will add the method to a mapping of *method_name* => Proc of method.
The annotated method **MUST** always take a single argument of `args`. The args are passed to the method from the html where required. See the spec folder of this project for examples.
```html
Assert Equals
This is an example of a basic assertion using assert_equals.
The greeting should be Hello World!.
```
## Development
When running the specs locally in the project use this:
`crystal run --no-debug spec/*.cr -- -l "./projects/spinach/spec"`
## Contributing
1. Fork it ()
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create a new Pull Request
## Contributors
- [Kingsley Hendrickse](https://github.com/kingsleyh) - creator and maintainer