ContinuousTest / Moose : Here Be Dragons and general overlay questions

872 views Asked by At

Has anyone ever come across the Here Be Dragons warning in Mighty Moose / ContinuousTests? enter image description here

This was placed beside a private method, probably because it's private and thus not easily testable - you might need magic armor to get this tested. Anyway, I also found this on the setter of a property, so I tried to reproduce it. Now I don't see any test run indicators beside my code anymore at all.

How can I get those back? What are the conditions for showing up? Thanks in advance!

3

There are 3 answers

1
ack On BEST ANSWER

The reason why you are seeing this message is that ContinuousTests takes a lot more than test coverage into account when giving feedback. With the margins that you see there you can get either green, yellow or red. Green means that changing this code is fairly safe. Yellow means that there is a bit of a risk changing that piece of code. Red means that if you change this code you are on your own. There is a good chance something will break if it is changed. If you hover over the icon you can see some statistics about the risk. If you right-click and choose "ContinuousTests->Get Affected Graph" you will see the coupling graph for this piece of code.

When the "here be dragons" message is shown it means that the code you are looking at is referenced at a lot of places in the code and no tests seems to be coupled to it or what is referencing it. So changing that code you are risking not only breaking that method but also breaking everything that indirectly uses it.

Hope that explains it.

0
Greg Young On

Wow I can answer this and just ran into this question many years later :) I am reasonably qualified to answer it as I wrote the software in question.

What it is telling you is that your code is not safe to change.

"When the "here be dragons" message is shown it means that the code you are looking at is referenced at a lot of places in the code and no tests seems to be coupled to it or what is referencing it. So changing that code you are risking not only breaking that method but also breaking everything that indirectly uses it."

Is pretty much correct.

What it is looking at is

this code

tests of this code

places this code is called from

places this code calls

tests of where this code is called

recursively

It essentially builds a graph (you can pull up the actual graph visually) of all the related code and the tests associated to that code then does a risk analysis of the code in question. As example on the risk analysis if I have a test that directly tests a method it is considered to be much better than a test that somehow covers a method nine levels down a call chain.

Does this make sense?

0
Sebastian Edelmeier On

Since no-one can explain, I'm gonna file this under WTF!?!?! and close it. A support request resulted in the following, which still leaves me kind of uninformed:

It's le a red zero but worse. Basically they show up in what appears to be a tangled mess of code with no tests through it. If I remember correctly th graph needs to have more than 30 odes in it with 0 test coverage as well as some il cycle attic complexity

Well, it's free...