Travis failing when Cucumber task pending?

Question

As title says, my travis-ci instance is telling me that my build is failing when I have cucumber step definitions that are pending (not undefined) - is there a way to stop this behaviour?

I can understand the reason why, but the undefined behaviour I have is undefined by purpose - I have no intention on doing that feature RIGHT NOW, but I know I want to keep the step definition down so I don't forget what I came up with. The reason I ask is because this behaviour (with it failing when I have a pending task) could end up masking real failures that actually matter.

Answer 1

There is a similar answer here which should be useful for you, the answer that he gives is:

I think cucumber gives non-zero process exit code either because of skipped or because of pending tests. Try to get it to not run any skipped, then any pending, then any skipped or pending tests and see what exit codes it gives. To see the exit code (in Unix), run it with something like:

cucumber ...args to select tests... ; echo $?

So basically you want to figure out what args you can provide to cucumber to have it pass and then provide a .travis.yml that runs that command. an example rake task for cucumber jasmine and rspec is here:

task :travis do
  ["rspec spec", "rake jasmine:ci", "rake cucumber"].each do |cmd|
    puts "Starting to run #{cmd}..."
    system("export DISPLAY=:99.0 && bundle exec #{cmd}")
    raise "#{cmd} failed!" unless $?.exitstatus == 0
  end
end

And read the docs for more info on creating a .travis.yml.

If all of that doesn't work, just create a bash script that catches the output and returns 0 in the right cases, I really doubt this is required though since I'm sure there's an option to cucumber to make it ignore pending.

EDIT: the cucumber docs say:

Pending steps

When a Step Definition’s Proc invokes the #pending method, the step is marked as yellow (as with undefined ones), reminding you that you have work to do. If you use --strict this will cause Cucumber to exit with 1.

Which seems to imply that they will not exit with 0 if you don't call --strict