[HELP]: Test setup

[kentcdodds]

Hey friends! I could use some help getting the setup for this thing tested! If you could please follow the instructions in the README and let me know:

1. Are they clear?
2. Does it work? (If not, please file an issue for the issue you're seeing)
3. What system are you on?
4. How could it be improved?

Thanks!

[callummr]

Windows 10, x64

First run I accidentally hadn't installed Mongo (my bad, readme is clear). It threw the relevant error (below) but then added Congrats! Your system is setup properly. You should be good to install and run things.

> testing-workshop@1.0.0 setup D:\dev\testing-workshop
> node ./scripts/verify.js && node ./scripts/install && npm start validate

The system cannot find the path specified.
there was an error determining your mongo version
{ Error: Command failed: "C:/Program Files/MongoDb/Server/3.2/bin/mongod.exe" --version
The system cannot find the path specified.

Not really a problem per se.

I then installed the latest mongo version for Windows (3.4.2 which is supported per readme) and got the same error. I noticed at line 74 of verify.js the version is hardcoded to 3.2

That's all for now as yarn is running incredibly slowly (problem on my end I'm pretty sure), will update with any more findings.

[kentcdodds]

That's really helpful! I fixed the congratulations thing. I'm not sure what I can do about the mongod version in the path on windows thing... Do you know how I could ensure that we're pointing to the right binary? I'd love to not have to have the full path...

[callummr]

Continued that convo in the issue I raised for it :)

Another thing, I set my git up with core.autocrlf true (ie. convert line endings to Windows on pull, back to unix on push) which I believe is pretty standard on Windows. Linting is pretty upset by this, outputting an error for every line of every file:

[lint] D:\dev\testing-workshop\api\models\User.js
[lint]     1:33  error  Expected linebreaks to be 'LF' but found 'CRLF'  linebreak-style

Not sure if the correct solution is changing the linting rules or git configuration. Most Windows editors will have no problem with LF line endings but newer developers or those only familiar with Windows might run in to issues later if they do change the git config. Also, changing the linting rules doesn't require anything extra of the user which could be considered a plus. Maybe.

[kentcdodds]

Ah, yeah, I keep forgetting about that line break stuff! I've added a .gitattributes file. You may need to re-clone to get that updated. Thanks!

[kentcdodds]

Hey @callummr, did the npm start script work for you? Did it pop open all the commands in different windows for you?

[edm00se]

Steps were clear, things didn't work for me in either of my main environments; details below.

Windows 7 - Result: 💩☹️

This one rambles a bit, sorry about that.

• Git BASH
• mongo installed from chocolatey is at v3.2, making it in a different relative path to the hard-coded one in package-scripts.j, as @callummr mentioned (your req's do state >=3.4.2, more just an FYI I had to upgrade outside my usual Windows package manager)
  • installing the latest (3.4.2) from mongodb.com actually parked things into the C:\Program Files\MongoDB\Server\3.4 path
• no yarn in this environment, used node ./scripts/install as was mentioned in the output to the log from npm run setup
  • of note, the default small window of Git BASH means user has to scroll up a ways to see what the npm equivalent is (otherwise they're just staring at a lot of "npm ERR! ..."); this is the message from scripts/verify.js
  • install via npm took a little while, there looks to be a lot of goodies in there!
• npm start launches three cmd.exe shell windows, at the correct repo path, but didn't execute anything
  • got the same results from cmd.exe as opposed to Git BASH
  • the above was on node 6.9.1, npm 3.10, upgraded to 6.9.5 and npm@4(.2.0)
  • Git BASH spawned shells, again nothing running (same for cmd.exe)
• I created a symlink of 3.4.2 to 3.4
• ran again, from cmd.exe while running "as Administrator" and again, no dice

macOS Sierra (10.12.3) - Result: 🤔☹️

• node@6.9.5, npm@4.2.0
• w/ yarn@latest (0.20.3)
• mongodb@latest via homebrew (3.2.6, running, via brew services ...)
• hyper
• default shell: zsh with oh-my-zsh
• install (npm run setup) was good, ./scripts/verify succeeds
• npm start launches the three child shell instances, w/ nothing running in them (there's also a terminal.app instance it launches in the background, looks like the npm start mongo)

Using it from terminal.app does launch the sub-shells with the commands in them (e.g.- npm start client), however it appears to be breaking on a space in the name of a parent directories. Moving my repo dir to my ~/Desktop and running from there, succeeds as expected, prompting for permissions and launching a browser tab.

If I get some time tonight, I may take another pass and see if I can find anything enlightening beyond the space in the directory name thing.

[kentcdodds]

hard-coded one in package-scripts.js

That's been dealt with. The instructions now ask you to add mongod to your PATH (with links showing you how to do that).

otherwise they're just staring at a lot of "npm ERR! ..."

Changed the script to be npm run setup --silent so you don't see npm ERR! everywhere. Thanks!

npm start didn't work

:-( If you have any tips on how to make this work, here's how that happens...

Based on your experience with npm start on mac with hyper/zsh, I'm thinking maybe it's not worth putting too much effort into making it work. Maybe I should just tell people to run each script individually. Honestly, most of the time they wont be running the app anyway (except for the E2E tests). They'll just be running the test scripts.

[edm00se]

Interesting; you may be right if they'll be spending most of their time on the test scripts. The troubling part to me was that terminal.app w/ zsh works fine (in a directory path without a space), so it seems to be an issue directly w/ how things are being handled in hyper's newly spawned shell instance.

[kentcdodds]

Well, if you look at the function that generates the script to run, it's pretty Terminal.app specific 😅 If we could make it work regardless of what terminal you use, we'd probably cover 80% of use cases.

[edm00se]

That makes perfect sense now. 🤔

[callummr]

@kentcdodds Sorry, early night. Just tried start and it launches three cmd instances but they aren't running anything. Think I see the issue, will PR if I can before I leave this morning.

Edit: #6

[kentcdodds]

@edm00se, if you get a chance to give it a go again, please do. Thanks to @callummr's changes I think we're ready!

[edm00se]

That definitely fixes the Windows issue I noted with the spawned shells lacking scripts to run.

[kentcdodds]

I'm now struggling with this:

It's more than annoying! I'm not sure what's up... I've done just about everything I can think of. I've added a TROUBLESHOOTING.md in the hopes that if someone runs into this one of those things will help them...

Could I get some more people to try the setup? It's changed a bit and I want to see if anyone else gets this...