Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cucumber overwrites variable values in output #915

Closed
enkessler opened this issue Sep 22, 2015 · 8 comments
Closed

Cucumber overwrites variable values in output #915

enkessler opened this issue Sep 22, 2015 · 8 comments

Comments

@enkessler
Copy link
Contributor

I have long known that 'puts' statements inside of a step definition are delayed until the step is complete. That is, you will go from seeing no output from a step to all of it at once when the step has finished running. I assume that this is the intended behavior of the pretty formatter.

Apparently, however, the formatter does not determine the value of the variable that it is printing out until the end. This results in incorrect output if, for example, I am in the habit of modifying a variable several times in a step definition and put-ing its value to the console so that I can debug something. All displayed values will be the same value instead of displaying the several different values that the variable went through.

See this gist to recreate the problem:
https://gist.github.com/enkessler/18c4837c865c59a287dc

(Note: I used cucumber 2.0.2)

@mattwynne
Copy link
Member

Hi Eric,

Yeah. I guess we could call #dup on the argument passed to our #puts method to alleviate this. Would you like to put together a PR for that?

Otherwise I'd suggest just calling $stderr.puts which will print to the output stream immediately.

@enkessler
Copy link
Contributor Author

I'll give it a go but it doesn't look like its build environment if friendly to Windows and that's all that I've got.

@enkessler
Copy link
Contributor Author

Well, I can at least run the suite but it's full of failures. I guess that I'll just try to not make it worse and leave it to you guys to handle any needed tweaks during the PR.

@mattwynne
Copy link
Member

Sorry about the build environment @enkessler. I'd like to fix that so other windows users can contribute. Are you able to give us some more concrete feedback? I'll make a new ticket.

@enkessler
Copy link
Contributor Author

I was having trouble installing some of the required gems that needed the devkit but it turns out that was due to me using one of the latest version of Rubygems...which doesn't work on Windows. So it's not you guys specifically, it's the Ruby ecosystem in general that could use more Windows love. After downgrading Rubygems, things installed fine.

My current hurdle is testing the solution. I'm avoiding writing a Cucumber test for it since it looks like you guys use your feature files as Relish documentation and you don't need some random test sticking out like a sore thumb. I'm avoiding writing an RSpec test because I'm not sure where to put it/how to set the objects up/what the relevant objects even are because I'm not familiar with the internal workings of Cucumber. That being said, the solution is being shown to work based on the gist that I initially provided.

Finally, even before I make any changes, the current code base does not pass all existing tests. I don't know if the repository is not in a clean state or perhaps there are other Windows issues that are causing the tests to fail. All of the RSpec tests pass but there are ~80 failing features. Due to the existing test failures and not being sure how to write the new test, I was hoping to take a 'I did not make it worse' approach and simply give you guys the implementation portion in the PR (the solution is a simple one line #dup call as you suggested).

@enkessler
Copy link
Contributor Author

Darn. The #dup/#clone approach will actively break "features/docs/gherkin/doc_strings.feature:56 # Scenario: DocString passed as String". I guess that copying a singleton object isn't handled well. Marshaling and unmarshaling the arguments keeps the tests happy but after reading the documentation on the Marshal module, I am not confident that it can be used with all objects either.

You know, on second thought, #puts just stringifies things so I'll try to simply convert everything to a string right then and there and that'll leave us with nice, new objects.

FYI: The test suite appears unstable. Although I can make changes and end up with the same failing tests as before, it sometimes takes a few tries to end up with the same set of failing tests. Several of them change from passing to failing and back again without any code changes between the two states.

@enkessler
Copy link
Contributor Author

Good to go. Still no tests but it passes the gist.

@lock
Copy link

lock bot commented Oct 25, 2018

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants