Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
> I'm interested in your take on RSpec and Cucumber?
I found that Cucumber misses a bit on its promise: in theory things are perfectly described by high level behaviours but in practice it's a bit leaky and I regularly had to work around the tool, which was of disservice to readability. After all if you are faced with a high level descriptive test but have to know about some internals as to why this or that case has to be tested or why it has to be written this or that way (sometimes tacky ways) then it's probably that the tool is not quite fit.
Rspec (or minitest/spec) eschews that: essentially it's just Ruby so you write what you need. The other side of the coin is that things you write might not be as "high level" as you initially want: you can have something working but very raw and possibly a tangled hard to maintain mess when it should be "higher level" (or several levels composed together). IOW the big advantage of Rspec is that it scales across from "lowest level" unit testing to "highest level" behaviour so it's always fit, but then it's on you to pick the "proper" level that fits and design your specs accordingly.
An example (not perfect by any means but gives a good idea of composition), here we extracted a bunch of functional ("integrated") behaviours into separate examples:
https://github.com/DataDog/dd-trace-rb/blob/57976d52bde573f9...
Note that some are nested, and with a flick they test behaviour when e.g `appsec` is enabled or `tracing` is disabled. This creates a ton of combinations for only a few tests and coverage goes through the roof.
Now here's how we use that:
https://github.com/DataDog/dd-trace-rb/blob/57976d52bde573f9...
Notice that magically every case is going to be tested and so we're absolutely sure that it works whatever a user toggles in their configuration.
Notice that we create a Rack app, and then the tests proceed, just picking whatever app is in that `let :app`, which leads me to something we have yet to do:
https://github.com/DataDog/dd-trace-rb/blob/57976d52bde573f9...
https://github.com/DataDog/dd-trace-rb/blob/57976d52bde573f9...
Notice how essentially just the `let :app` setup differs, but tests are entirely similar to the Rack ones (IIRC save for a couple that don't apply to Rack) so actually the overall behaviour can be entirely extracted and shared too! The result would be a per-framework test suite would be a) set up :app for that specific framework and b) a single `it_behaves_like "my super high level behaviour"` line, shared across all frameworks.
Bonus (not sure you're familiar with it so here goes): this is tested using Rack::Test, which thanks to Rack's design provides a bunch of request methods (`get` and so on) that merely call the Rack stack as if it were a web server. IOW the whole app code is called just as if there were say Puma or Webrick in front but without ever creating a web server or a socket or whatnot, so it's stupidly fast, and since we're straight in the Ruby code we can mock or stub or allow/expect methods to be received or whatever is needed to our heart's content.
Every bit conspires to produce a simple, readable, compact test suite that combinatorially covers every case and runs in a stupidly short amount of time.
It mostly comes from the intentional design of open classes, thus the namespace organisation is fundamentally decoupled from the filesystem: any Ruby file has to be able to contain any class/module, otherwise one can't add to an open class/module†!
There are a bunch of issues about this upstream about this, e.g: https://bugs.ruby-lang.org/issues/14982
My take on it: https://github.com/lloeki/package-ruby
† ... via `class` and `module` keywords, as one could always include/extend/prepend or use `module_eval`/`class_eval`/`instance_eval`.
> debugger
Check out the latest IRB on 3.3, it finally gives Pry a run for its money!
https://github.com/ruby/irb#debugging-with-irb
$ ruby test.rb