-
Notifications
You must be signed in to change notification settings - Fork 23
Design Philosophy
Gregory Haskins edited this page Dec 4, 2016
·
1 revision
Here are a few semi-organized notes on the design philosophy behind Spectrum.
- Keep the API cohesive and understandable
- Prefer to exactly replicate something from another BDD tool (RSpec, Jasmine, Mocha, Cucumber, etc.), when possible. When an exact copy isn’t possible, use a translation that would least surprise users of Spectrum and of those other tools. JUnit similarity is lower on this list than others.
- Functionality should be equally available at all levels of nesting. If something only works at the top level, or can’t be applied in isolation at lower levels, then it probably needs to be re-worked.
- Avoid reflection, which implies avoiding annotations. The compiler is our friend.
- Have a solid, generic core that is simple to extend for plugin authors and power users.
- Move toward a more modular distribution. In the future, there should be a spectrum-junit4 that runs on top of JUnit4, spectrum-junit5 for JUnit 5, maybe even spectrum-standalone for a CLI runner. All would share a common spectrum-core with the various DSL syntaxes and domain model available for any of those frameworks.