Purpose

While it is preferable to leave all tests enabled, I had a need to disable tests for specific mgems while leaving all others enabled. For example, some mgems which my project requires contain unit tests that depend on remote servers, and the tests will always fail if those servers are not accessible (e.g. due to firewall restrictions or temporary internet outage). Thus, this PR makes it possible to disable some tests while leaving the rest of the test suite enabled.

Syntax

conf.gem 'mruby-noisygem' do |g|
  g.skip_test = true
end

I think the assignment-style syntax, g.skip_test = true|false, might allow for more flexibility within a complex build script, but if a more declarative style (g.skip_test) is preferred, this is an easy change that I can make.

Implementation Notes

If mruby-test/mrbgem.rake encounters a gem with disabled tests, it simply does not generate a call to GENERATED_TMP_mrb_#{g.funcname}_gem_test(mrb). Instead, it adds a warning to $asserts so that the builder won't forget that they have disabled these tests.

I considered also suppressing the generated test code in gem_test.c. If we did that, the generated mrbtest bin should be smaller. However, I decided to leave it in place, in case the builder wants to call the test functions directly for some reason (perhaps with a custom test driver, for example). Therefore, in this PR the test logic is still generated and its symbols are still exported as before, but it just isn't executed by the default mrbtest.

In order to add the warnings to $asserts, I had to #include <mruby.h> (and a few others) in the generated mrbtest.c and delete typedef struct mrb_state mrb_state. I am not sure if there was a specific reason that the original version relied upon a typedef instead of including mruby.h, so if a dependency on mruby.h is not desirable, then we could create a function in driver.c and call that function instead.

Testing

I did give some thought to writing a test case for the proposed behavior. I considered creating a dummy mgem, which contains a single assertion that always fails. Then, I could modify build_config/ci/*.rb to disable the dummy mgem test with skip_test = true. When the test passes, the dummy test would be disabled and therefore not generate a failing assertion. However, I decided to wait and see what you think about this approach. It seems heavy handed and maybe you know a better way. Also, I'm not sure where a dummy gem should live (would test/ be a good location?). I am happy to add this kind of test case if desired.