Travis CI support

[cromwellryan]

• [x] Include Gemfile so Travis installs the necessary test gems (minitest)
• [x] .travis.yml (if necessary)
• [x] Build badge

relates #10

[agriffis]

Thanks! Any thoughts on why the build is failing? It runs locally for me with just rake (which is different from Travis running with bundle exec rake)

$ rake
Ignoring ffi-1.9.14 because its extensions are not built.  Try: gem pristine ffi --version 1.9.14
Ignoring json-2.0.1 because its extensions are not built.  Try: gem pristine json --version 2.0.1
/usr/bin/ruby test/rubypants_test.rb
Ignoring ffi-1.9.14 because its extensions are not built.  Try: gem pristine ffi --version 1.9.14
Ignoring json-2.0.1 because its extensions are not built.  Try: gem pristine json --version 2.0.1
Run options: --seed 33836

# Running:

...........

Finished in 0.034897s, 315.2169 runs/s, 3753.9473 assertions/s.

11 runs, 131 assertions, 0 failures, 0 errors, 0 skips

[agriffis]

Hmm, it seems to be because lib/rubypants/version.rb has

class RubyPants

and lib/rubypants/core.rb has

class RubyPants < String

and when running with bundle exec rake then these conflict. I don't know the best practice for resolving this, though.

[cromwellryan]

RE class RubyPants < String I'll take a look and submit back. If it's impactful and something you'd rather do in another PR, we can override the test command for Travis in the .travis.yml to just use rake vs bundle exec rake.

[cromwellryan]

At first glance, I think this might be outside the realm of this particular PR.

The common pattern would be to use a top level module of RubyPants which would expose the version. Here are a few examples:

• flip
• sinatra
• rake

I think the best approach for this particular PR is to override the testing task for travis until this adjustment is made.

Thoughts?

[agriffis]

Thanks for the research. I agree regarding fixing the superclass mismatch in a separate PR.

Thanks for helping out!