thought-driven / bummr

Update your gems in separate commits. Identify any that fail your build.
MIT License
234 stars 23 forks source link

Black box test #55

Closed odlp closed 5 years ago

odlp commented 6 years ago

To prevent regressions, such as #44, it'd be useful to have higher-level tests which invoke bummr in a separate process, with no stubbing.

This first test exercises bummr update. Overview of the steps:

lpender commented 5 years ago

Oh one other thing--could we update the README and remove the bit about Aruba doubles ?

Thanks!

odlp commented 5 years ago

Hi Lee,

No worries about the delay. I just rebased off master and noticed this test fails now - Bummr doesn't seem to be committing despite the Gemfile & lockfile updating, and the 'Hello world' Rake command passing.

I'll try and figure out if this a genuine regression or whether the black-box test itself needs updating.

lpender commented 5 years ago

Nice catch! I'm thinking it may be because of the git wrapper that was added... Should we add the command to the CircleCI build so that it fails properly ?

odlp commented 5 years ago

@lpender thanks for figuring out the issue!

Re:

If so, I'm wondering if you thought about, or experimented at all about caching the response i.e. via something like webmock or VCR?

My current thinking is that for it to be a true integration / black-box test that it should hit the network to really prove everything works. The downside is the test suite could become unreliable if the network isn't available (so we should be sparing with these tests). Hopefully the high-level tests provide confidence everything works so it's worth the trade-off vs. potential instability if the network is down.

One tweak we could make is to tag the specs which hit the network:

-describe "bummr update command" do
+describe "bummr update command", :network do
   let(:session) { JetBlack::Session.new(options: { clean_bundler_env: true }) }
   let(:bummr_gem_path) { File.expand_path("../../", __dir__) }

Then say you're offline, developing on a plane, then it's possible to run specs except those which touch the network:

bundle exec rspec --tag '~network'

https://relishapp.com/rspec/rspec-core/docs/command-line/tag-option#exclude-examples-with-a-simple-tag

Would this be useful?