3 files left to go, and they're behaving oddly so I'm leaving them out
in this pass. Looks like 21 deprecations left.
Signed-off-by: Ryan Davis <zenspider@chef.io>
This activates a BUNCH of tests but keeps us green.
Whether these tests are valid or not is not being addressed here.
Signed-off-by: Ryan Davis <zenspider@chef.io>
This was the next most expensive require in the analysis.
Also rearranged the way that ui handled tables to be lazy.
```
% SLOW=1 time rake test:functional
before: Finished in 681.514579s, 0.5136 runs/s, 2.9919 assertions/s.
after : Finished in 642.655918s, 0.5446 runs/s, 3.1728 assertions/s.
```
Signed-off-by: Ryan Davis <zenspider@chef.io>
Not sure how it was supposed to work in the first place. The plugin in
question depends on ordinal_array and that wasn't in that fixture dir.
Switching to 2 is all it apparently needed.
This does cause yet another double-load warning (VERSION already
defined). I don't know how we're supposed to get around that with the
way we've set up these tests.
Signed-off-by: Ryan Davis <zenspider@chef.io>
This time between:
+ PluginManagerCliDefinitionTests#(?:test_plugin_registered
+ PluginLoaderTests#test_load_mock_plugin_by_gem
Signed-off-by: Ryan Davis <zenspider@chef.io>
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>
These tests both involve dynamic un-rooted classes. As such, they have
no name and thus print like #<Class:0xXXXXXXXX:...>. I switched one to
a describe instead of Class.new(Minitest::Test) and the other I
stringified the anonymous class.
Signed-off-by: Ryan Davis <zenspider@chef.io>
+ Turn off verbosity in Rakefile by default. Use `rake V=1` to turn back on.
+ MiniTest -> Minitest everywhere.
+ MiniTest::Unit::TestCase -> Minitest::Test everywhere.
+ Updated minitest doco urls to official and up-to-date site.
+ Normalize requires. Only needs "minitest/autorun" and "minitest/pride".
Signed-off-by: Ryan Davis <zenspider@chef.io>
This PR adds 5 closely related plugin types, which allow a plugin to implement new DSL methods / keywords. The mechanism to activate the plugins are all very similar - basically, in a particular location in the code, `method_missing` is implemented, and is used to activate the particular type of DSL being requested.
4 of the DSL plugin types relate to code that could appear in a profile control file.
* outer_profile_dsl plugins allow you to extend the code in profile Ruby files that appear outside `control` or `describe` blocks.
* control_dsl plugins allow you to extend the code within `control` blocks.
* describe_dsl plugins allow you to extend the code within `describe` blocks.
* test_dsl plugins allow you to extend the code within `it`/`its` blocks.
Finally, the `resource_dsl` plugin allows you to extend the code used within custom resources.
Basic unit tests are provided to prove that the plugin types are properly defined.
A simple plugin fixture defining DSL hooks (based on favorite foods) is included, and is exercised through a set of functional tests.
The plugin developer docs are updated to describe the 5 DSLs.
*Note*: Implementing a plugin using any of the DSL plugin types is experimental. The contexts that are exposed to the DSL methods are private and poorly documented. The InSpec project does not claim the APIs used by these plugin types are covered by SemVer. Plugin authors are encouraged to pin tightly to the `inspec` gem in their gemspecs.
Motivation for this plugin comes from the desire to allow passionate community members to implement things like "2 out of 3" tests, example groups, improved serverspec compatibility, "they/their" and other "fluency" changes, as well as make it possible for future work by the InSpec team to be implemented as a core plugin, rather than a direct change to the main codebase.
* unit tests for plugin conf file class, all skip
* File path stuff works
* Validation works
* Add works
* Added remove_entry
* Save works - ready to refactor others
* Rework Loader to use ConfigFile
* Modify loader and installer to use the config file class
* linting
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
* Unit and functional tests for a reject list facility
* Implementation of plugin reject facility
* Initial draft of reject list
* Add option to search to hide test fixture by default
* Fix test
* PR feedback
Signed-off-by: Clinton Wolfe <clintoncwolfe@gmail.com>
