Doesn't render tickmarks for mocha theme on Windows

[TAGC]

The tickmarks from the "mocha" and "mocha-parallel" theme get rendered as question marks on Windows, as shown below.

Tested on:

• Git Bash (through Mintty 2.8.5)
• Cygwin (through Mintty 2.9.0)
• cmd

I'm using 64-bit Windows 10.

[radarsh]

Hi @TAGC, have you tried doing this from the FAQs?

[TAGC]

That's probably it. I'm having trouble changing the encoding used during testing, though. In your build.gradle script you set it via the systemProperty method for your test task:

gradle-test-logger-plugin/build.gradle

Lines 75 to 85 in 328bdfa

	test {
	testClassesDirs += sourceSets.functionalTest.output.classesDirs
	classpath += sourceSets.functionalTest.runtimeClasspath
	systemProperty 'file.encoding', 'UTF-8'
	testlogger {
	theme 'mocha'
	}
	exclude 'com/adarshr/gradle/testlogger/functional/**'
	}

I'm using the Kotlin DSL and tried doing the equivalent in mine:

val test by tasks.getting(Test::class) {
    useJUnitPlatform { }

    systemProperties["file.encoding"] = "UTF-8"
    systemProperties["foo"] = "bar"
    println(systemProperties)

    testLogging {
        events("PASSED", "FAILED", "SKIPPED")
    }

    testlogger {
        setTheme("mocha")
    }
}

The "foo" property gets set but the file encoding still remains as windows-1252:

But yeah if I fix that, I guess that'll resolve this issue.

[TAGC]

Creating a gradle.properties file in my root project directory containing org.gradle.jvmargs='-Dfile.encoding=UTF-8' causes the Gradle test task to use UTF-8 file encoding (I see -Dfile.encoding=UTF-8 instead of -Dfile.encoding=windows-1252 now).

I still see question marks, but I guess the next step is to change the terminal code page as shown in the FAQ. I'll update when I've tried that.

[radarsh]

Is it not systemProperty "foo", "bar" in Kotlin DSL? Just guessing as I'm not familiar with Kotlin DSL syntax.

I still see question marks, but I guess the next step is to change the terminal code page as shown in the FAQ. I'll update when I've tried that.

Unfortunate truth about Windows :-(

[TAGC]

I checked - my charset is already 65001 and it doesn't work:

Are you sure it's not just a problem with the way your library tries to render it? I've got a JS project and I can see the tickmarks render fine in PowerShell when I run the tests in that:

[radarsh]

I have done a similar comparison in the past and isolated the problem to the way Java prints Strings on the console. The JS libraries on the other hand, ultimately delegate to native code to do the printing.

But I have it working on my Windows machine. Let me share some settings in sometime.

By the way you can try cloning this repo and running the tests to see if it's a problem with the plugin code or some configuration in your project.

./gradlew test should print the results using the mocha theme.

[TAGC]

I tried it, I see this:

[radarsh]

I had to set JAVA_OPTS at shell level. Just realised that's what the FAQ says, although not very explicit. See below, let me know if it helps:

PS C:\Development\workspace\gradle-test-logger-plugin> ./gradlew test --tests "*does not log*"

> Task :test

  com.adarshr.gradle.testlogger.logger.ConsoleLoggerSpec

    ? does not log empty strings

  1 passing (3.6s)


BUILD SUCCESSFUL in 9s
7 actionable tasks: 1 executed, 6 up-to-date
PS C:\Development\workspace\gradle-test-logger-plugin> $Env:JAVA_OPTS = "-Dfile.encoding=UTF-8"
PS C:\Development\workspace\gradle-test-logger-plugin> chcp 65001
Active code page: 65001
PS C:\Development\workspace\gradle-test-logger-plugin> ./gradlew clean test --tests "*does not log*"

> Task :test

  com.adarshr.gradle.testlogger.logger.ConsoleLoggerSpec

    √ does not log empty strings

  1 passing (2.8s)


BUILD SUCCESSFUL in 12s
8 actionable tasks: 8 executed

[TAGC]

Ah okay, yeah that works, thanks. Shame that it has to be done through the environment variable though and doesn't pick up on the equivalent setting defined in gradle.properties.

[radarsh]

I will clarify this in the documentation. I too went through multiple hoops before eventually realising that setting an environment variable was the most reliable option.