Added mutant markers

[JKutscha]

This is intended to replace the mutations view in the long run and provide more features.

Currently there are markers which indicate a mutant in the corresponding java class.

[JKutscha]

@LorenzoBettini and @echebbi, what are your thoughts on this kind of change?

[echebbi]

I'm not sure if that will effectively replace the Mutations view (I personally think that the tree is very convenient to get a quick overview) but Markers sure are a great addition! Combining them with Code Minings may be handy as well but that would be another PR not to overload this one.

You currently tagged the PR as a draft, are you planning more features or are you just not done with the implementation yet?

[JKutscha]

You currently tagged the PR as a draft, are you planning more features or are you just not done with the implementation yet?

I'm not done yet with implementing all of it. For example, I don't have a way to get rid of the markers automatically, if the content of the editor changes.

Also, testing is a big problem for me on this specific implementation, because I don't really know how this should be tested. It mostly uses Eclipse extension points and I don't think testing the output of the tasks view would be a good idea?! I would be happy to hear your ideas on testing.

[echebbi]

Also, testing is a big problem for me on this specific implementation, because I don't really know how this should be tested. It mostly uses Eclipse extension points and I don't think testing the output of the tasks view would be a good idea?! I would be happy to hear your ideas on testing.

I think that tests should just programmatically query all the available markers and check the Pitclipse-related ones. The content of the Tasks view and the display of the marker in the editor is Eclipse IDE's duty, we can trust it for that and thus don't have to check the UI.

[JKutscha]

I think that tests should just programmatically query all the available markers and check the Pitclipse-related ones. The content of the Tasks view and the display of the marker in the editor is Eclipse IDE's duty, we can trust it for that and thus don't have to check the UI.

This sounds like a good idea, but I think this will result in low coverage. What do you think of that, @LorenzoBettini?

[LorenzoBettini]

I think that what you're implementing should be somehow testable (and as usual, I'd go for full coverage, possibly by delegating the handling of corner cases, like CoreException, to utility classes). As @echebbi suggested, once the markers are generated you can trust Eclipse to display them correctly, but the generation of the markers with expected contents should be tested.

I'm not sure I understand why we leverage the Tasks View, though...

[JKutscha]

I think that what you're implementing should be somehow testable (and as usual, I'd go for full coverage, possibly by delegating the handling of corner cases, like CoreException, to utility classes). As @echebbi suggested, once the markers are generated you can trust Eclipse to display them correctly, but the generation of the markers with expected contents should be tested.

I will look into the testing of the generating process.

I'm not sure I understand why we leverage the Tasks View, though...

Because the Task View provides some powerful functions. For example you can filter only a specific type of mutations, double click to jump to the file, delete markers which are not from interest or can only highlight mutations of the file you are currently working on. Also, you can create your own "Task View" from there which is handy to filter mutations, but leaves the Tasks View itself alone.

After working with the Task View for a bit and the mutations in it, I found it really nice.