search

stryker-mutator / mutation-testing-elements

🗃 A schema for mutation testing results with the web components to visualise it 📊
Apache License 2.0
28 stars 19 forks source link

TestFiles should have a Language property for syntax highlighting #1503

Open rouke-broersma opened 2 years ago

rouke-broersma commented 2 years ago

Source files have a Language property that can be set which is used for syntax highlighting. Test files don't seem to have this property. This should be available so the syntax highlighting of test files can use the proper language highlighting.

nicojs commented 2 years ago

I don't like that to be honest. We base syntax highlighting of test files on the extension, which should be the case for source files as well.

rouke-broersma commented 2 years ago

File extensions don't necessarily have to be correct on all platforms, systems and ecosystems. There might even be conflicting file extensions between languages. I think it's safer if the tool generating the report specifies which language the files are since they will know best. Mutation testing elements can make a best effort guess, the mutation testing tool will know for sure.

nicojs commented 2 years ago

Yes, that makes sense, but couldn't I can't come up with an example of overlapping file and language types. In general, we are pretty good at coming up with unique extensions for source code files.

What is the use case for language, other than syntax highlighting? Because we only support a small subset of languages for syntax highlighting and I know for sure there is no overlap in these file extensions.

rouke-broersma commented 2 years ago

The case comes first and foremost from a consistency perspective. Files have a language property, TestFiles do not.

nicojs commented 2 years ago

In that case I can agree with an optional language property. I would also opt to make the language property optional for source files 🤷‍♀️

hugo-vrijswijk commented 2 years ago

I don't think I've ever seen an inconsistent filename for source files. But adding a language might be more beneficial for places where we've forgotten to add support for the filename in the report. For Node, there's a huge number of extensions you can have (js, ts, jsx, jsm and some combinations of all those)

nicojs commented 2 years ago

Yes, so either I place the logic of extension recognition in StrykerJS, or in mutation-testing-elements. I personally prefer mutation-testing-elements in that case, closer to the "view" 🤷‍♂️.

Either way it should be optional, as code highlighting is not required for a report.

rouke-broersma commented 2 years ago

Imo the schema should be as platform independent as possible. If you put the language detection in html elements any other consumer of the json would also need to implement language detection. I think it's cleaner to provide a complete json containing all information necessary.