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

Provide an option to use dasherized test names #14915

Closed
GabrielCW opened this issue Feb 8, 2017 · 9 comments
Closed

Provide an option to use dasherized test names #14915

GabrielCW opened this issue Feb 8, 2017 · 9 comments

Comments

@GabrielCW
Copy link

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
Copy link
Member

Turbo87 commented Feb 8, 2017

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.

@pixelhandler
Copy link
Contributor

@GabrielCW perhaps this is an issue that belongs on the ember-cli project instead of the ember.js project. The blueprints are part of https://github.com/ember-cli/ember-cli/issues

@locks
Copy link
Contributor

locks commented Feb 10, 2017

@Turbo87
Copy link
Member

Turbo87 commented Feb 10, 2017

agreed, the relevant blueprints for this issue live in ember.js and ember-data now and that is where they should be discussed.

@pixelhandler
Copy link
Contributor

@locks oh forgot, they used to live in ember-cli, my bad.

@pixelhandler
Copy link
Contributor

@Turbo87 @GabrielCW @locks - I'm curious if this should be discussed on an RFC issue instead of in two places ember.js and data issue trackers.

Use RFC issues to propose a rough idea, basically a great place to test the waters.

@Turbo87
Copy link
Member

Turbo87 commented Mar 17, 2017

@pixelhandler I'm not sure if this would actually need a full blown RFC to be honest, but feel free to write one 😉

@GabrielCW
Copy link
Author

@pixelhandler @Turbo87 I went ahead and wrote the RFC, it is available here.

@Turbo87
Copy link
Member

Turbo87 commented Mar 20, 2017

@GabrielCW awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants