search

permissions-dispatcher / kompile-testing

Testing tools for kotlinc and kapt
Apache License 2.0
70 stars 3 forks source link

Truth support #7

Open hotchemi opened 5 years ago

hotchemi commented 5 years ago

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

mannodermaus commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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?