dependency-analysis-gradle-plugin VS Truth

And perhaps https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin

I'd love to hear more about the complexity of configuring multi-module builds. Dependency management is an obvious point here and there are plugin that can help here (like https://github.com/autonomousapps/dependency-analysis-android-gradle-plugin for instance), but I'd be happy to hear more pain points.

Added a new test suite, named "functionalTest", and configured it to use the Spock test framework, along with three dependencies: Truth, TestKit-Truth, and the project itself. This reveals the interesting point that, by default, new test suites don't have the project under test on the classpath, which enables true black box testing if you're into that kind of thing.

A little more than two years ago, in October 2019, I began work on my first significant open source project, the Dependency Analysis Gradle Plugin. I had just left a job where I had done relatively little coding, was taking a month off, and wanted to get back into a building mode and learn some new things. I decided to explore the domain of unused-dependency detection. The nearest competitor I was aware of was the Gradle Lint Plugin from the Netflix Nebula collection. However, as that plugin has never supported Android projects, that meant I had an exploitable niche—if only I could exploit it.

Tony actually wrote a plugin that does just this! Check it out!

(The commit is available here.)

Truth or AssertJ for easier assertions in tests with better exceptions

Truth is a nice unit testing assertion library

Configured the default test suite (named "test", i.e., the "unit tests") to use the JUnit5 (aka JUnit Jupiter) test framework, and to add Truth as a testImplementation dependency.

Hey all - I created a project for myself two years ago to experiment with MPP, based on Google Truth but rewritten in 100% Kotlin, which I called Truthish.