Tests fail due to differences in polish characters

[piotrgajow]

After adding Clover to the project all of my tests where I use polish diacritic characters started failing.

E.g. test case

void 'Should throw exception when user not found'() {
    when: 
    service.getUser(19999L)

    then:
    def ex = thrown DomainException

    and: 
    ex.message == 'Nie znaleziono takiego użytkownika'
}

Fails with:

Condition not satisfied:

ex.message == 'Nie znaleziono takiego użytkownika'
|  |       |
|  |       false
|  |       2 differences (94% similarity)
|  |       Nie znaleziono takiego u(ż-)ytkownika
|  |       Nie znaleziono takiego u(ż)ytkownika
|  Nie znaleziono takiego użytkownika
errorhandling.DomainException: Nie znaleziono takiego użytkownika

It seems that code instrumentation messes with the file encoding or something...

My configuration is

clover {
    testIncludes = ['**/*Test.java', '**/*Spec.groovy']

    targetPercentage = '90%'

    compiler {
        encoding = 'UTF-8'
    }

    contexts {
        statement {
            name = 'log'
            regexp = '^.*LOG\\..*'
        }
    }

    report {
        html = true
        filter = 'log'

        testResultsDir = project.tasks.getByName('test').reports.junitXml.destination
        testResultsInclude = 'TEST-*.xml'
    }
}

When I remove Clover setup, all of the tests are passing.

[Alex-Vol]

This is a bug. Clover supports specifying the source file encoding but we only supply the encoding to the compiler tasks and not the clover-setup tasks. I can make a fix for that easily I think. I will have to add some UTF-8 encoded characters in my integration tests.

[Alex-Vol]

It seems the clover-setup interface we use in this plugin to instrument the code does not support the encoding attribute. clover-instr Ant task does this but we are not using it this way. This may take a bit longer than I hoped to get fixed.

[Alex-Vol]

According to documentation for Clover the build will use the default platform encoding if not specified by parameters. Perhaps you can try setting the default JVM encoding to UTF-8 and test again.

You would need to do this at the JVM parameters used to start Gradle. You can add such parameters to your gradle.properties in the project like this.

org.gradle.jvmargs=-Dfile.encoding=UTF-8

[piotrgajow]

Adding this setting in gradle.properties did not help.

Without Clover everything works fine, including loading files from the file system, so I guess it should not be JVM settings issue?

[Alex-Vol]

Well, I was hoping what the documentation specified would apply. It is possible the JVM setting did not have an effect the way I understood it from the Clover documentation. I am afraid this will not be a quick fix since it may require significant changes to support. Unless I find a workaround soon it will be some time before I can make these changes.

[Alex-Vol]

By the way, I was unable to reproduce this issue on a Linux build machine. Are you building this on Windows @piotrgajow ? That may help me better understand why the suggested workaround did not have an effect.

[Alex-Vol-SV]

After I spent some time researching Clover implementation I cannot find an option that would correct this behavior. I am becoming convinced that this is a bug in Clover's implementation of code instrumentation. If they used a file stream that does not have the proper encoding set and have no way of specifying the encoding the transformation of the source code during the build to prepare for compilation will destroy any characters that are not in the expected character set.

I will continue this line of research to find out the answer and come up with a fix. It may involve a change in Clover instead of this plugin or perhaps a combination.

[Alex-Vol-SV]

It seems we are in luck. There is an undocumented encoding option for clover-setup. I am not sure how that was missed in the Clover documents. I found it in the Clover source code which is just plain obvious when I look at it.

I am preparing a proper integration test for this case to prove it is fixed and will try to get a new milestone build out.

[piotrgajow]

Good to hear this! Yes I am currently working on Windows (10 & 8.1).

[Alex-Vol-SV]

@piotrgajow I have attempted to fix the issue with the undocumented encoding option and it does not seem to work. It may be a bug in Clover after all. However, during the testing process I found a way to work around the issue until I get it fixed. Adding this to your environment seems to have the desired effect and corrects the problem in my tests.

set GRADLE_OPTS=-Dfile.encoding=UTF-8

Please try this and let me know if you get the issue or not. I will continue searching for the right fix and make an update.

You may need to stop the Gradle daemon after setting this to become effective. gradlew --stop will do this.

[Alex-Vol-SV]

From my investigation I came to the conclusion that the issue exists between Groovy tests and Java production code. The Clover instrumentation process seems to obey the encoding selection for Java but not so for Groovy, the result is that the instrumented code in Java gives the unmodified string results and Groovy tests verify with altered/corrupted strings.

With that in mind making the tests use Java constants instead of the literal string values might also work around the issue since the Java constants would have been compiled with the Java compiler and would not be corrupted.

[Alex-Vol-SV]

I was able to fix the issue @piotrgajow without the need to have major rework. As it happens there were a couple of places other then the clover-setup where we had neglected to specify the encoding. With the changes in the new branch I created just now the code works as expected. I will try to wrap this up in a new 2.1.2 release this week.

[piotrgajow]

Great!

I have also tested the set GRADLE_OPTS=-Dfile.encoding=UTF-8 option and it works.

[Alex-Vol]

Great, thanks for testing the workaround. The fix has been merged to master branch and will be posted as soon as possible.

[Alex-Vol]

Fixed in 2.1.2

[piotrgajow]

Confirmed. Everything works fine. Thanks!