Specifically, if these were run in this order:
+ PluginLoaderTests#test_load_mock_plugin_by_gem
+ PluginInstallerInstallationTests#test_install_a_gem_from_local_file
the latter would fail.
The failure was in test setup. The solution was partially to crib off
of and normalize with LoaderTest setup/teardown and partially to set extra things.
Specifically:
+ HOME wasn't being set so it was finding my ~/.inspec/plugins.json
+ ENV wasn't being reset for Gem.paths
+ Installer wasn't being reset correctly, so plugins were known across tests.
Signed-off-by: Ryan Davis <zenspider@chef.io>
+ Added SLOW=1 to appveyor (I hope?) and travis.
+ Off by default.
Speeds up installer tests from ~5.5 seconds to ~0.5 seconds.
Once this is established, we can push this up to the main helper and
generalize if it works out for us.
Signed-off-by: Ryan Davis <zenspider@chef.io>
+ Do extra cleanup of loaded_specs for the dependencies.
+ Ensure rake is actually activated.
Fixes#4030.
Fixes#4026.
Signed-off-by: Ryan Davis <zenspider@chef.io>
As commented, I'm happy to push this to our tests, but it does seem
odd that we'd install rdoc/ri for plugins.
Signed-off-by: Ryan Davis <zenspider@chef.io>
Extracted a GLOBS const so it can be reused and only updated in one
place.
Added test:list that prints out all known test files.
Changed test:isolated to use the glob, AND to use system (sh would
fail out on the first failing test, so much of the looping mechanism
was redundant. I also changed the loop to run all of the tests
regardless of outcome, so you can see all the failures.
Signed-off-by: Ryan Davis <zenspider@chef.io>
+ float? comparison can raise a TypeError
+ octal? comparison was allowing non-octal values (which cast to 0)
+ symbol comparison was casting to a string, but then doing an == check instead of casecmp.
The latter seems optional, but consistent with the intent of cmp.
Signed-off-by: Ryan Davis <zenspider@chef.io>
obj.method(name).call(*args) == obj.send(name, *args)
```
Calculating -------------------------------------
method+call 2.561M (± 2.2%) i/s - 12.816M in 5.006835s
send 6.299M (± 2.4%) i/s - 31.501M in 5.004045s
Comparison:
send: 6299002.5 i/s
method+call: 2560909.2 i/s - 2.46x slower
```
There aren't any direct tests for this? But I forcefully failed 2
functionals and then verified they passed after my change.
Not sure how (or if) to write tests against rspec matchers in a
meaningful way, even tho all I really want to test is a plain ole
method in it. I'll poke to see if it is possible / practical.
Signed-off-by: Ryan Davis <zenspider@chef.io>
Moved exec_inspec to inspec_path.
Added new exec_inspec that invokes ruby w/ -Ilib (expanded).
Decouples from bundler and/or needing inspec-bin to be installed.
Signed-off-by: Ryan Davis <zenspider@chef.io>
Can also try to use the bundler version first and then fall back to
VERSION... but VERSION is absolutely free.
Happy to push an edit to this to remove the comment or fold it in.
Signed-off-by: Ryan Davis <zenspider@chef.io>
This was testing serverspec compatibility, but those days are long past us and this is a deprecated resource now. This will quiet our tests up a bit.
Signed-off-by: Tim Smith <tsmith@chef.io>
Before you had to kick off kitchen via Rake as the Rake task build the local gem we injected into the cookbook. Now we do it within Test Kitchen using a feature that didn't exist when this was all written. Also --output is your friend and greatly reduces the complexity of all this.
Signed-off-by: Tim Smith <tsmith@chef.io>
I'd suggest starting to structure kitchen testing like this with a
directory and subdirs to keep the kitchen testing gems out of the
root Gemfile entirely.
This still mounts the root dir in /inspec so the root Gemfile
is still what you're running the rake tests against.
By having an extra layer of subdirs, then you can split up different
use cases like the rake-testing vs. the audit cookbook testing.
Otherwise it'll be a mess of having to manage different kitchen.yml
files that require way too many different drivers/provisioners/verifiers
