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

Add a new test case for leading dots in file extension declaration. #518

Merged
merged 1 commit into from
Dec 13, 2016

Conversation

JimiC
Copy link
Member

@JimiC JimiC commented Dec 12, 2016

No description provided.

@JimiC
Copy link
Member Author

JimiC commented Dec 12, 2016

@robertohuertasm Is there an issue with this PR or you want to do same more testing?

@robertohuertasm
Copy link
Member

I just want to find some time to review this once I get home 😉

@robertohuertasm
Copy link
Member

@JimiC I think we don't need this. I mean, filenames can have a dot at the beginning (.httpaccess, .appveyor.yml, .babelrc ...)

@JimiC
Copy link
Member Author

JimiC commented Dec 13, 2016

If you take a closer look filename cases are excluded. This test is on for those mark as extensions.

@robertohuertasm
Copy link
Member

robertohuertasm commented Dec 13, 2016

Sorry @JimiC, I was misled by a previous comment from #510 and didn't pay proper attention:

What is possible is to check that the extension doesn't have a leading dot if it's a file extension.

I thought that when you said file extension you were referring to a file extension with filename attribute set to true as opposite to just extension. Never mind, just a language issue 😞

It's ok then 😀

@@ -20,6 +20,16 @@ describe('generating icons', function () {
expect(iconGenerator.getPathToDirName(toDirName, fromDirPath)).toEqual(pathTo);
});

it('file extension should not have a leading dot', function () {
files.supported
.filter(function (file) { return !file.filename; })
Copy link
Member

Choose a reason for hiding this comment

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

I guess that you've chosen to favor readability instead of performance by double looping over the files.supported collection, haven`t you?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeap. The impact isn't noticeable.

@JimiC
Copy link
Member Author

JimiC commented Dec 13, 2016

Glossary:

filename: A string that classifies the entire name as an extension.
extension: A string that classifies as a file extension.
language: A string that classifies as a languageIds supported extension.

Hope this helps us speaking a common domain language.

@@ -144,7 +154,7 @@ describe('generating icons', function () {
var fileExtensions = iconGenerator.buildJsonStructure().files.names.fileExtensions;

files.supported
.filter(function (file) { return !file.filename && !file.languages; })
Copy link
Member Author

Choose a reason for hiding this comment

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

This removal is due to the decision to include the language supported extension in the test.
At first I excluded them but after you clarified it I forgot to change it back.

Copy link
Member

Choose a reason for hiding this comment

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

If everything is fine I'll proceed with the merge then.

Copy link
Member Author

Choose a reason for hiding this comment

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

I just pointed this out in case you were wondering.
I'm a GO.

@robertohuertasm robertohuertasm merged commit 26562a7 into vscode-icons:master Dec 13, 2016
@JimiC JimiC deleted the more_test branch December 13, 2016 10:47
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.

None yet

2 participants