Exception in second_curtain

[orta]

..................................................................................................................................../Users/travis/build/artsy/eigen/vendor/bundle/ruby/2.0.0/gems/second_curtain-0.2.0/lib/second_curtain/parser.rb:23:in `parse_line': undefined method `fails=' for nil:NilClass (NoMethodError)
    from /Users/travis/build/artsy/eigen/vendor/bundle/ruby/2.0.0/gems/second_curtain-0.2.0/bin/second_curtain:8:in `block in <top (required)>'
    from /Users/travis/build/artsy/eigen/vendor/bundle/ruby/2.0.0/gems/second_curtain-0.2.0/bin/second_curtain:7:in `each_line'
    from /Users/travis/build/artsy/eigen/vendor/bundle/ruby/2.0.0/gems/second_curtain-0.2.0/bin/second_curtain:7:in `each_line'
    from /Users/travis/build/artsy/eigen/vendor/bundle/ruby/2.0.0/gems/second_curtain-0.2.0/bin/second_curtain:7:in `<top (required)>'
    from /Users/travis/.rvm/gems/ruby-2.0.0-p353/bin/second_curtain:23:in `load'
    from /Users/travis/.rvm/gems/ruby-2.0.0-p353/bin/second_curtain:23:in `<main>'
    from /Users/travis/.rvm/gems/ruby-2.0.0-p353/bin/ruby_executable_hooks:15:in `eval'
    from /Users/travis/.rvm/gems/ruby-2.0.0-p353/bin/ruby_executable_hooks:15:in `<main>'
F** TEST FAILED **

https://magnum.travis-ci.com/artsy/eigen/builds/5392603

[ashfurrow]

Hmm. Looks like a situation I had thought was not possible – that a test could fail before both a test suite and a test case were created. The offending line is:

latest_test_suite.latest_test_case.latest_command.fails = true

Based on the error undefined method fails= for nil:NilClass, which I assume is Ruby's null pointer deference error, we can fix it pretty easily by wrapping it with some conditional statements. However, I'd be concerned that we could be ignoring failing tests. It's a shame that xcpretty has gobbled up the test run output, as I'd like to see what was going on. @orta: any chance this is happening locally?

[orta]

afraid not, passes fine locally to me. I can do a run on travis without xcpretty.

[ashfurrow]

That would be super – I'd like to get the test output so we can set up a second_curtain test for this condition.

[ashfurrow]

Oh, I think I know what this is. If a test case case fails, second curtain tries to set the last recorded kaleidoscope command's fail property to true. But if there wasn't a last recorded command, because that test case didn't contain a "ksdiff" line, then that line is actually incorrect. Second curtain is making the assumption that whenever a test case fails, it must be due to a snapshot test case failure. I'll send a PR with a simple conditional checking if there is a command present.

This won't fix the slightly greater – but probably not that big of a deal – problem of having the following scenario.

expect(view).will.haveValidSnapshot(); // pass, but does emit a "ksdiff" line
expect(1).to.equal(2); //fails, but the kaleidoscope command from the previous line is recorded as a failure in second curtain

That's a pretty edge case, so I'll file an issue on it and leave it for now.