Provide an option to use dasherized test names

When tests are generated, there name is humanized to make it more readable by humans. This process removes the dashes from the base strings, meaning some-component’s test name will be some component.

I recently had a problem where I couldn’t run test for one of my components with ember test --filter="some-component". To make it more confusing, jshint tests ran well for the expected files, but the test itself didn’t run. @Turbo87 helped me figure out it was because the test name was some component, therefore not matching some-component.

Considering the test’s name is humanized, it was counter intuitive to think that it may be used in resolution.

Could an option be added to the generator, in order to allow for the string to stay dasherized? With that option, a test generated for some-name/space/some-component would actually contain some-name/space/some-component.

Or could it even be used as default? Is the current humanized form relied upon?

[Turbo87]

I tend to agree that this is confusing default behavior and I often hand edit the name myself because the humanizer invented some bad looking name for the component or module. For a foo-bar component we already have the name foo-bar (or component:foo-bar) and the FooBarComponent when using globals. Why should there be a third name foo bar which does not related to the filename or the global? This seems confusing to me and I would support an effort to use the dasherized component/module name instead, which correlates with the filename it is stored in.

[Turbo87]

@GabrielCW awesome, thanks!