This is a proposal to use different approach to write test classes.
In https://github.com/soundcloud/lightcycle/pull/64 we talked about lightcycle-processor test can't be run directly from IDE, and after I checked lightcycle-processor test source code, looks like for now Android Studio can't find the file from resources directory.
In this pull request I rewrote the approach from getting the file from resource directory to write the java source file as a String directly in the test classes.
After thinking and rewriting about this approach this is my conclusion
Pros :
Can be run directly from IDE, so we can check the test easier compared to running from terminal
Easier to debug (Everything is in one place, IDE will seperate the fail test stacktrace for us)
Test separated into specific usage (Activity Injection, Fragment Injection, Support Fragment Injection, etc)
Cons :
Java source string is written directly into test classes, which will make the test classes bigger than before
Note :
I also changed org.truth0.Truth.ASSERT.about into com.google.common.truth.Truth.assertAbout because org.truth0.Truth class is deprecated
In InvalidCaseTest, I also added error message checking to prevent false positive
This is a proposal to use different approach to write test classes.
In https://github.com/soundcloud/lightcycle/pull/64 we talked about lightcycle-processor test can't be run directly from IDE, and after I checked lightcycle-processor test source code, looks like for now Android Studio can't find the file from resources directory.
In this pull request I rewrote the approach from getting the file from resource directory to write the java source file as a String directly in the test classes.
After thinking and rewriting about this approach this is my conclusion
Pros :
Cons :
Note :
org.truth0.Truth.ASSERT.about
intocom.google.common.truth.Truth.assertAbout
becauseorg.truth0.Truth
class is deprecated