recommend ember s over ember test --server

[NullVoxPopuli]

this page: https://guides.emberjs.com/release/tutorial/part-1/automated-testing/
says to use ember test --server -- which is problematic for a multitude of reasons, and while it'd be better to fix those issues, most folks want one command to use.

ember s and visiting /tests is only half the resources of running both ember s + ember test, which is best for low-spec computers.

[MelSumner]

which is problematic for a multitude of reasons

Can you say more about this? What are the issues?

[NullVoxPopuli]

test -s regularly:

• does not reflect file changes
• is slow (due to doubling building resources on a system (more of a problem on low-end systems))
• causes people think this is the only way to get at the tests
• crashes
• has super buggy terminal UI with overlaying testem stuff and errors, it's a mess

[NullVoxPopuli]

I think we should probably get rid of test -s, honestly

[rwjblue]

I'm not sure we should get rid of it per-se, but I definitely think that the primary way to run tests should be ember s + /tests/.

[runspired]

ember s + /tests/ is the one that is problematic for a multitude of reasons in my mind. ember test --serve is a huge lifeline, and the only way I trust running tests. All but one of the issues @NullVoxPopuli points out are addressed merely by separating the build and serve commands. the one that is not addressed is does not reflect file changes, which I've never experienced so I'm not sure what is being referred to.

is slow (due to doubling building resources on a system (more of a problem on low-end systems))

Generally speaking it's identical if you hook it up to an existing build (which could also be an existing serve). This is fairly trivial to do: ember test --serve --path="./dist"

causes people think this is the only way to get at the tests

Most of the time I have the opposite problem, people think /tests/ is the only way to get to the tests and have no idea a better tool exists for them.

crashes

I've never had it crash for a reason that wasn't a build issue that would also have crashed the serve command, separating out the build command from the test and serve commands fixes this issue for both.

as super buggy terminal UI with overlaying testem stuff and errors, it's a mess

this happens only when you don't separate them because the build and the test commands are competing.

A few things that ember test is particularly good at which /tests is not.

• quickly running multiple test instances against multiple commits for better side-by-side debugging
• giving you the ability to run headless and watch the state of your tests without launching a browser / looking at the browser unless needed
• not colliding with urls in your app
• not wrecking your build for non-test related dev and serving if you so choose
• being able to slide an altered command (like ember exam) into the same workflow for improved functionality
• the potential for us to improve things such that we could build and run fewer tests if desired (I've done this with a custom test tree based on filter, we should build it in)

[NullVoxPopuli]

We have some comparing the do then, i think.

I've personally experienced issues with using ember test for development (but not with ember s) on:
Big apps and small apps
Old apps and new apps
Classic and octane apps
All the apps 🙃