Set up DatabaseCleaner for tests #28
Conversation
There was a problem hiding this comment.
I want database cleaning to be something that can be easily opted into from any test, which is why the feature is activated on examples tagged as db: true (see support_db_cleaning.rb for this).
However, I still want us to provide the convenience of database cleaning by default for feature specs (i.e. tests defined using Capybara's RSpec.feature API). This file here provides this via a "loose coupling"-style of approach: it adds the db: true metadata to any example marked as a feature.
There was a problem hiding this comment.
I think this is sensible. I did something very similar with with :slice metadata, because my persistence is configured at the slice level, my slice tests are structured as spec/slices/slice_name and automatically receive this metadata, and the integration detects whether or not the slice in question has persistence configured.
There was a problem hiding this comment.
Nice. Structuring the tests around slices is something I'd like to add in a future version too. This would let you do things like you already do here, and also other neat things, like give us a way to provide different factories per slice, etc.
But as per my below, I'm keeping things un-opinionated for now, just until we can get all the basics in place (2.2 is the last stop on that journey!).
| all_databases = -> { | ||
| slices = [Hanami.app] + Hanami.app.slices.with_nested | ||
|
|
||
| slices.each_with_object([]) { |slice, dbs| | ||
| next unless slice.key?("db.rom") | ||
|
|
||
| dbs.concat slice["db.rom"].gateways.values.map(&:connection) | ||
| }.uniq | ||
| } |
There was a problem hiding this comment.
I made this a proc because if I instead made it a method, then I'd need a place to put it. In my own apps I use module Test (and various nested modules within it) to put utility code like this, but for standard Hanami apps, I don't think we're yet at the point where we can introduce a structure like that. I'd like to do it, but it will need a bit more thought on the approach, as well as additional effort put into docs, both of which too much to fit in our remaining time before 2.2.
And so we have the proc. It remains local, so no concrete method naming required, and given the size of this file, I think it's still readable enough.
There was a problem hiding this comment.
I agree with your caution. While RSpec is clearly the default in the community, it would be good to be forward-thinking and allow something new and interesting to be used in addition to just minitest, and that flexibility will be hard.
What concerns me about RSpec is how difficult parallelism is with it, which contributes to long-term slow test suites in my experience. The modular separation of Slices in Hanami would otherwise make parallel testing very attractive.
There was a problem hiding this comment.
Cool, thanks for considering this, @alassek. Glad to hear you agree.
(I'd love for us to provide a parallel testing experience in the future!)
Resolves #27