I previously mentioned:
The functionality in expectations.scenarios was borne out of compromise. I found certain scenarios I wanted to test, but I wasn’t sure how to easily test them using what was already available in (bare) expectations. The solution was to add expectations.scenarios, and experiment with various features that make testing as easy as possible.
Truthfully, I’ve never liked scenarios – I’ve always viewed them as a necessary evil. First of all, I hate that you can’t mix them with bare expectations – this leads to having 2 files or 2 namespaces in 1 file (or you put everything in a scenario, meh). You either can’t see all of your tests at the same time (2 files), or you run the risk of your tests not working correctly with other tools (expectations-mode doesn’t like having both namespaces in 1 file). Secondly, I think they lead to sloppy tests.
The second complaint causes me to get on my soap-box about test writing, but never motivated me to do anything. However, as expectations-mode has become more integral to my workflow, the first issue caused me to make a change.
As of 1.4.17 you should be able to write anything that you would usually write in a scenario in a bare expect instead.
I’ve already published several blog entries that should help if you’re interested in migrating your scenarios to bare expectations.
One feature that is noticeably missing from bare expectations is the stubbing macro. I decided to leave the stubbing macro out as I believe it’s just as intention revealing to use with-redefs & constantly, and I always prefer to use core functions when possible.
If you were previously using stubbing, your test can be converted in the following way.
(stubbing [a-fn true]
;;; can now be written as
(with-redefs [a-fn (constantly true)]
A nice side effect of removing stubbing is the reduction of indention if you are using both stubbing and with-redefs. This seems like the right trade-off for me (less indenting, relying on core functions that everyone should know); however, I’m not against adding stubbing again in the future if it becomes a painfully missing feature.
There is one type of scenario that I haven’t yet addressed, interleaved expectations. I found zero of these types of scenarios in my codebases; however, I’m addressing these types of scenarios here for completeness.
(expect a b)
(expect c d))
Any scenario that has interleaved expectations can be converted in the following way:
(assert (= a b))
expectations 1.4.17 still has support for scenarios, so you can upgrade and migrate at your own pace. I’ll likely leave scenarios in until the point that I change some code that breaks them, then I’ll remove them. Of course, if you prefer scenarios, you’re welcome to never upgrade, or fork expectations.
If you run into issues while converting your scenarios, please open an issue on github: https://github.com/jaycfields/expectations/issues?state=open
Read more at the source