Identify if-block on compile-time

[AlienCoder]

Hello Community,

there are unit-test-frameworks like Munit which also deliver a code-coverage-report.

It can identify if an if-block within a tested method has been run through by the compiler, when this method was called.

How can I write a code, wicht can do this as well?
How can I make the compiler recognize an if-block or a while-loop or something like that?

Kind regards
AlienCoder

[Jason O'Neil]

The same team who made "munit" also made "mcover", and is probably what you want to check out:

https://github.com/massiveinteractive/mcover

There is an example in the repo of how to use it with munit.  I haven't used it in a while, but I think it did detect coverage at a block level (if, while etc), not just a function level.  You'll need to double check though.

Jason

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[AlienCoder]

Hello Jason,

thank you for your response.

Although Munit and MCover are very handy tools, I think, that there are good reasons not to use them.

First of all, you give away a lot of controle. Of cause, some processes should not be left in the hands of a human tester and so necessarily need to be automated. But the Test-Runner overwrites your .hxml file. The process is wired through the .munit file, the .hxml file and a macro call with several redundancies.And it is not always clear what is the source for the Test-Runner-Build. Is it the the .hxml file, .munit or the macro call (and probably all of them together, as they need to have redundant entries). Finally no-one knows what the framework is doing in detail, which can be very criticle in some cases when you have to look what has gone wrong. And you have no chance to reconstruct the mistakes.

And the final point, why I do not love it, is that I see some conceptional gabs. For example, every method call within a test method is counted as a test, wether or not it has an effect on the returned value (which then could be seen as an indirect test).

So I would like to write some very simple testmethods and a coverage-report and fit them to my needs step by step.

Do you have an idea, how the compilers knows what kind of codeblock he is passing (and he is not passing)?
How does the compiler know, that an if-case has been run through negatively?

Thanks again for your efforts.

Kind regard
AlienCoder

[Philippe Elsass]

Admittedly munit/mcover have a few obscure aspects (and quirks) but from what I see you really misunderstood how it work.

Firstly there is no simple way to do code coverage, and mcover does that using macros. It can be used without munit but munit easily integrates it.

Secondly munit first generates an hxml and some classes, then it won't overwrite them. Except the one class listing the test classes which are detected.

Finally not all functions are counted as tests: only those with the @:Test annotation.

Philippe

[AlienCoder]

Of cause you are right:

MCover does not 'overwrites' the .hxml file, it overrides it. Sorry for my bad english.

But you are a little unprecise in your explanation:

What you have described with "those with the @:Test annotation" is what I have meant with "test method" in opposite to a source code method.

Those methods itself do not have any effect on the coverage report at all.

Only the source code methods called within those test methods are counted for the code coverage. But it does not matter, if you write e.g. an assertThat() (hamcrest matcher) to test the returned value of this source code method.

For example:

@test
public function testMultiply() : Void
{
     MyMath.multiply( 3, 2 )

}

... is seen as a test of the source code method MyMath.multiply.

MCover does not ask, if you actually have tested the result of the method. Calling it within a test method is fair enough and leads to a coverage of 100 %.

Kind regards
Alien Coder