I’ve got a test structured something like: ```context("when starting a Foo") { context("and thin...

# kotest

[bbaldino]

I’ve got a test structured something like:

context("when starting a Foo") {
    context("and thing A happens") {
        should("throw an error") {
        }
    }
    context("and thing B happens") {
        should("throw an error") {
        }
    }
}

and when I get a failure, in the junit output I just get: "should throw an error" for context, which is ambiguous between those 2 cases. Is there a way to get the full context “tree” when a failure happens?

[sam]

not in junit as it doesn't understand these nested tests

[sam]

by junit you mean the xml ?

[bbaldino]

damn

[bbaldino]

yeah

[sam]

kotest has it's own xml that is compatible that allows you to tell it to use the full name

[sam]

https://kotest.io/docs/extensions/junit_xml.html

[bbaldino]

ah ok…i’ll look into that. thanks!

[bbaldino]

@sam just getting a chance to take a look at this…what dependency do I need to get JunitXmlReporter ? (from the link you sent here: https://kotest.io/docs/extensions/junit_xml.html)

[bbaldino]

Also, any tips on where to find how to do that reporter config block in maven?

[sam]

kotest-extensions-junit or -junit-xml

[sam]

one of the two

[bbaldino]

great, thanks

[bbaldino]

(kotest-extensions-junit5?)

[sam]

yeah that's sounds like it

[bbaldino]

ah damn, only since 4.3.0 looks like. is that what requires a more recent kotlin version?

[sam]

it's been around for ages

[sam]

what version are you running

[bbaldino]

i’m on 4.1.3 and still on kotlin 1.3

[sam]

4.3 doesn't need 1.4

[bbaldino]

cool…i’ll try upgrading

[bbaldino]

is it possible to do that build output dir piece in maven?

[sam]

yeah I'd imagine so but not sure how as I don't use maven

[sam]

You could just hardcode it if you know your build path

[sam]

it's just a system property

[sam]

Or maven might expose some variables ${project.buildDir} or something

[bbaldino]

yeah the prop should be doable i think…dunno what useJUnitPlatform() is doing

[sam]

useJUnitPlatform is just telling gradle to enable junit5platform support

[sam]

you don't need that in maven

[bbaldino]

ok cool

[bbaldino]

hm, i don’t see JunitXmlReporter in either of those…trying to look at github but don’t see either of those repos under `kotest`…are they under a different name?

[sam]

https://github.com/kotest/kotest/blob/master/kotest-extensions/kotest-extensions-j[…]vmMain/kotlin/io/kotest/extensions/junitxml/JunitXmlReporter.kt

[sam]

simplest thing to do if you don't want to upgrade is just copy that class into your test sources and use it from there

[bbaldino]

ah, didn’t realize they were all under kotest-extensions. thanks

[sam]

you need jdom2 on your path too https://github.com/kotest/kotest/blob/master/kotest-extensions/kotest-extensions-junitxml/build.gradle.kts

[bbaldino]

it looks like kotest-extensions-junitxml has been around for a while, it has a 4.1.3 version. and JunitXmlReporter seems like it’s been around since that timeframe

[sam]

yeah I know it's been around for ages

[bbaldino]

but for some reason it still doesn’t show up.

[sam]

I wrote it years ago

[sam]

gonna be quicker to copy n paste that file

[bbaldino]

sure, but i’d rather keep it more “official”

[sam]

upgrade to 4.3 is the way to keep it official 🙂

[bbaldino]

that doesn’t appear to fix it

[bbaldino]

i think it’s because it’s requiring i do <type>pom</type> when adding the junitxml dep

[sam]

because its maven

[sam]

try https://search.maven.org/search?q=a:kotest-extensions-junitxml-jvm

[sam]

io.kotestkotest extensions junitxml jvm4.3.0

[bbaldino]

ah yeah, that should do it

[bbaldino]

ok, that and moving to 4.3.2 finds JunitXmlReporter (it’s not in 4.1.3 looks like)

[bbaldino]

thanks sam 👍

[bbaldino]

@sam sorry to keep harping on this…should I expect that the JunitXmlReporter overwrites the existing files? I do see the proper names in the file JunitXmlReporter spits out, but it was in a different directory. When I change the output directoy in JunitXmlReporter to where the other files are written to it looks like I end up with the original ones, not the ones with the full names from JunitXmlReporter

[sam]

It's something that would run alongside the existing one

[bbaldino]

Ok, so I should have those output to a different location and then have whatever’s reading them look at that location?

[sam]

kotest has no control over what reports gradle is generating

[sam]

exactly

[bbaldino]

Ok…one other question: i should not expect that this changes the console output of junit/surefire or whatever…those will still have the shorter test case names?

[sam]

yes

[bbaldino]

ok

[sam]

this is just an XML file generator

[bbaldino]

thanks

[sam]

do you want longer names in surefire ?

[bbaldino]

ideally, yeah

[sam]

add a ticket - I was thinking of adding some configuration options for this to 4.5

[sam]

so if you write it up, I'll implement it

[bbaldino]

ok cool, will do

[bbaldino]

https://github.com/kotest/kotest/issues/2168

[sam]

nice

[sam]

by longer test names I assume you mean the full test path for nested tests

[bbaldino]

right

[bbaldino]

i’ll clarify that

[bbaldino]

Ah, already ahead of me 🙂