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

Test bin command #1980

Closed
wants to merge 4 commits into from
Closed

Test bin command #1980

wants to merge 4 commits into from

Conversation

hpurmann
Copy link
Contributor

@hpurmann hpurmann commented Nov 22, 2016

Summary
This PR is a response to #1804

In the first step, I added a test for the existing behaviour. I was about to fix the bug @shnhrrsn reported. But then I noticed that none of yarns commands work in subdirectories. This is certainly a difference compared to npm. Is this intended?

We could add logic to find the current package root. I did so locally by traversing the folders up and searching for a package.json, then taking this as the cwd. It would add some complexity which could lead to other bugs. What do you think?

And a minor thing: Do we want to tell the user when he uses too many arguments (like we do in yarn why) or do we want be consistent with npm bin and just work, no matter how many arguments got passed to bin?

@hpurmann hpurmann changed the title [WIP] Test bin command, make yarn look for package root? [RFC] Test bin command, make yarn look for package root? Nov 24, 2016
@hpurmann
Copy link
Contributor Author

@torifat, @kittens, any thoughts on being able to execute yarn in sub-directories?

@@ -19,6 +19,6 @@ export function run(
config.registries[RegistryYarn.registry].folder,
'.bin',
);
console.log(binFolder);
reporter.log(binFolder);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will output an ansi code at the beginning of the line that resets the cursor to the start making it unsuitable for consumption via another tool.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh ok, interesting. Is there a good way to test the console output of this command without using the reporter?


const fixturesLoc = path.join(__dirname, '..', 'fixtures', 'bin');

async function runBin(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use the helper method that I cleaned up in #2007?

Copy link
Contributor Author

@hpurmann hpurmann Nov 25, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok sure, had a pretty similar thought about this boilerplate code.

@bestander
Copy link
Member

@hpurmann, what is left to get this merged?
I think it would be a good start to get this feature right.

@hpurmann
Copy link
Contributor Author

hpurmann commented Feb 28, 2017

Thanks for having a look at this.

Actually a few things are missing here:

  • I need to use the helper method @kittens cleaned up in DRY up command tests #2007
  • I need to know how to test the output of the command if I'm not allowed to use the reporter (see comments) For example I could spy on the console
  • Do you want to only have the test or do we want to also change the behaviour (that yarn bin works in sub-folders)? Currently, most of yarns commands do not work in sub-folders. This should maybe be first discussed as an RFC

@bestander
Copy link
Member

  1. Let's spy on console for simplicity.
    An alternative would be to use a reporter that does only console.

  2. Let's start with a test, merge it and move on to the fix discussion

Sinon provides an easy way to spy on objects and to clean up after each test case.
The problem here is that I can't speficy a directory from where I'd like to simulate calling `bin`.
Therefore, a test like that doesn't work.
@hpurmann
Copy link
Contributor Author

hpurmann commented Mar 1, 2017

  1. I use the helper method now but got a problem with it (see below in 3). Maybe @kittens or you @bestander can help me with it?
  2. I spy on console and use sinon to facilitate resetting the spy after each test case and cleaning it up in the end.
  3. I still pushed a skipped test for the sub directory thing which makes clear that my current approach for these tests is not working. Ideally, I want to tell yarn to execute the bin command from a specified directory (the fixtureLoc). Then, in the test expectation, I want to check whether it told me the correct ./node_modules/.bin path in that directory. Unfortunately, the test does create a temporary directory by concatenating the random path and the specified name (e.g. "subdir"). So if I'm using this information generated by the test, I do not actually test anything.

@hpurmann hpurmann changed the title [RFC] Test bin command, make yarn look for package root? Test bin command Mar 1, 2017
@@ -71,6 +71,7 @@
"gulp-watch": "^4.3.5",
"jest": "^19.0.2",
"mock-stdin": "^0.3.0",
"sinon": "^1.17.7",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think jest can spy on its own without sinon

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, didn't know this. I'll change this. Can you give me a hint how to handle the problem described in 3.?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re 3, maybe you should not test for Path but rather test that a script from bin can be executed?

@bestander
Copy link
Member

@hpurmann, are you blocked by something on this PR?

@hpurmann
Copy link
Contributor Author

No, currently just missing time. Will get back to it.

@bestander
Copy link
Member

Hey, @hpurmann, your contribution is very much welcome.
Once you have a chance to work on it open a new PR.
I'll close it for now to not keep unactionable PRs open.

@bestander bestander closed this May 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants