Truth support

[hotchemi]

https://mobile.twitter.com/JorgeCastilloPr/status/1081473043749367808

[mannodermaus]

I have some experience with writing custom Truth code, so I could definitely work on this. My question however is, what would the API surface of this look like? As Jorge mentions, this should be a separate artifact on top of the main one.

I'm thinking about something along the lines of this:

// Prepare
val compilation: Compilation = kotlinc().withProcessors(...).compile()

// Check for success
assertThat(compilation) // from the "kompile-testing-truth" library
  .succeeded()
  .generatedFile(...)
  .source() // at this point, it's a normal Truth StringSubject
  .isEqualTo("...")

// Check for failure
assertThat(compilation) // from the "kompile-testing-truth" library
  .failed()
  .errors() // at this point, it's a normal Truth ListSubject
  .contains("...")

Thing is, would this really be that big of a benefit over the current API? It's just about equally as fluent.

[hotchemi]

Seems compile-testing provides some Truth-coupled API to give users fluent ways to assert and show error/warning message(and also perhaps both are maintained by the same team)? Right now we only have minimal set of assert ways that were necessary for PD test suite. But yea..it'd be almost the same as current one except assertThat in my opinion😅And I'm not sure the position of Truth among Kotlin community actually..already dominant?😇

Refs:

https://javadoc.io/doc/com.google.testing.compile/compile-testing/0.15
http://google.github.io/truth/comparison

[mannodermaus]

@JorgeCastilloPrz, allow me to weave you into this convo since the request came from your end. What would be requirements for a Truth integration with regards to the block above from your perspective?