Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://gitlab.com/AntonMeep/silly
Better test runner for the D programming language. No nonsense.
https://gitlab.com/AntonMeep/silly
TDD bdd dlang dub no-nonsense test test runner
Last synced: about 2 months ago
JSON representation
Better test runner for the D programming language. No nonsense.
- Host: gitlab.com
- URL: https://gitlab.com/AntonMeep/silly
- Owner: AntonMeep
- License: 0bsd
- Created: 2018-07-19T18:56:18.675Z (about 6 years ago)
- Default Branch: master
- Last Synced: 2024-05-02T21:41:02.813Z (5 months ago)
- Topics: TDD, bdd, dlang, dub, no-nonsense, test, test runner
- Stars: 13
- Forks: 6
- Open Issues: 11
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-d - silly - Better test runner for the D programming language. No nonsense. (Testing Frameworks / Bare metal / kernel development)
README
silly [](https://gitlab.com/AntonMeep/silly) [](https://gitlab.com/AntonMeep/silly/commits/master) [](https://gitlab.com/AntonMeep/silly/commits/master) [](https://gitlab.com/AntonMeep/silly/blob/master/LICENSE) [](https://gitlab.com/AntonMeep/silly/tags)
=====
**silly** is a modern and light test runner for the D programming language.
# Used by
[Optional](http://optional.dub.pm/), [expected](http://expected.dub.pm/), [ddash](http://ddash.dub.pm/), and more!
> Got a cool project that uses **silly**? [Let us know!](https://gitlab.com/AntonMeep/silly/issues)
# Features
- Easy to install and use with dub
- No changes of your code are required to start using silly
- Seamless integration with `dub test`
- Named tests
- Multi-threaded test execution
- Filtering tests
- Colourful output
# Getting started
Add **silly** to your project:
```
$ dub add silly
```
This should be it! Try to run tests:
```
$ dub test
```
If it succeeded then congratulations, you have just finished setting up **silly**! Make sure to add more tests and give them nice names.
# Troubleshooting
Unfortunately, setup isn't that easy sometimes and running `dub test` will fail. Don't panic, most of the issues are caused by the quirks and twists of dub. Here are some suggestions on what to check first:
## Make sure `main()` function isn't defined when built in `unittest` mode
So, instead of this:
```d
void main() {
}
```
Do this:
```d
version(unittest) {
// Do nothing here, dub takes care of that
} else {
void main() {
}
}
```
## Make sure there is a special `unittest` configuration in your dub.json/dub.sdl
```json
{
...
"configurations": [
{
"name": "executable"
},
{
"name": "unittest"
}
]
}
```
See also [#32](https://gitlab.com/AntonMeep/silly/issues/32).
> **Pro Tip**: dub configurations can have `dependencies` as well! You may want to add silly as a dependency only for the `unittest` configuration to indicate that it's only used for tests.
## Make sure there is no `targetType: executable` in `unittest` configuration in your dub.json/dub.sdl
Instead of this:
```json
{
...
"configurations": [
...
{
"name": "unittest",
"targetType": "executable",
...
}
]
}
```
Do this:
```json
{
...
"configurations": [
...
{
"name": "unittest",
...
}
]
}
```
See [#12](https://gitlab.com/AntonMeep/silly/issues/12) for more information.
## Nothing helped?
Open a new [issue](https://gitlab.com/AntonMeep/silly/issues), we will be happy to help you!
# Naming tests
It is as easy as adding a `string` [user-defined attribute](https://dlang.org/spec/attribute.html#UserDefinedAttribute) to your `unittest` declaration.
```d
@("Johny")
unittest {
// This unittest is named Johny
}
```
If there are multiple such UDAs, the first one is chosen to be the name of the unittest.
```d
@("Hello, ") @("World!")
unittest {
// This unittest's name is "Hello, "
}
```
# Command line options
**Silly** accept various command-line options that let you customize its behaviour:
```
$ dub test --
Options:
--no-colours Disable colours
-t --threads Number of worker threads. 0 to auto-detect (default)
-i --include Run tests if their name matches specified regular expression. See filtering tests
-e --exclude Skip tests if their name matches specified regular expression. See filtering tests
--fail-fast Stop executing all tests when a test fails
-v --verbose Show verbose output (full stack traces, location and durations)
-h --help Help information
```
# Filtering tests
With `--include` and `--exclude` options it's possible to control what tests will be run. These options take regular expressions in [std.regex'](https://dlang.org/phobos/std_regex.html#Syntax%20and%20general%20information) format.
`--include` only tests that match provided regular expression will be run, other tests will be skipped.
`--exclude` all of the tests that don't match provided regular expression will be run.
> Using both options at the same time will produce unexpected results!
# Best practices
- Running tests in multi-threaded mode (default) can potentially cause issues, try running tests with `--threads 1`
- Although unittests inside of nested classes and structs are discovered and executed by Silly, it may be unreliable. Consider having unittest blocks on the toplevel