Update README

README.md

@@ -20,7 +20,7 @@ bit easier for you.
 Add the following to `project/plugins.sbt`:
 
 ```scala
-addSbtPlugin("com.github.reibitto" % "sbt-test-shards" % "0.1.0")
+addSbtPlugin("com.github.reibitto" % "sbt-test-shards" % "0.2.0")
 ```
 
 ## Configuration
@@ -72,19 +72,33 @@ shardingAlgorithm := ShardingAlgorithm.Balance(
 )
 ```
 
-As you can see, filling this out manually would be tedious. Ideally you'd want to derive
-this data structure from a test report. If that's not an option, you could also get away
-with only including your slowest test suites in this list and leave the rest to the fallback
-sharding algorithm.
+As you can see, filling this out manually would be tedious and would require constant maintenance
+as you add/remove tests (particularly if the tests are expensive). sbt automatically generates
+test report xml files (JUnit-compatible format) when tests are run, and sbt-test-shards can consume
+these reports so you don't have to manually manage this yourself. Example usage:
 
-Eventually this plugin will be able to consume test reports itself so that you won't have to
-worry about it at all.
+```scala
+shardingAlgorithm := ShardingAlgorithm.Balance.fromJUnitReports(
+  Seq(Paths.get(s"path-to-report-files")), // these will usually be located in the `target` folders
+  shardsInfo = ShardingInfo(testShardCount.value)
+)
+```
+
+For there to be test reports you have to first run `sbt test` on your entire project. And there's also
+the issue that these files won't exist in your CI environment unless you cache/store them somewhere.
+I'd recommend storing them remotely somewhere and then pulling them down in CI before running the tests.
+And upon successful CI completion, publish the newly generated test reports remotely to keep them up to date.
+This can be anywhere such as S3 or even storing them in an artifact as resources and publishing to a private
+Maven repo.
 
 ### Additional configuration
 
 If you're debugging and want to see logs in CI of which suites are set to run and which
 are skipped, you can use `testShardDebug := true`
 
+Also you can run `testDryRun` to see how each suite will be distributed without actually
+running all the tests and waiting for them to complete.
+
 ## CI Configuration
 
 ### GitHub Actions

src/main/scala/sbttestshards/ShardingAlgorithm.scala

@@ -1,6 +1,7 @@
 package sbttestshards
 
-import sbttestshards.parsers.{FullTestReport, JUnitReportParser}
+import sbttestshards.parsers.FullTestReport
+import sbttestshards.parsers.JUnitReportParser
 
 import java.nio.charset.StandardCharsets
 import java.nio.file.Path
@@ -10,8 +11,14 @@ import scala.util.hashing.MurmurHash3
 // This trait is open so that users can implement a custom `ShardingAlgorithm` if they'd like
 trait ShardingAlgorithm {
 
+  /** Prior test report that can be used by some sharding algorithms to optimize
+    * balancing tests across different shards.
+    */
   def priorReport: Option[FullTestReport]
 
+  /** Returns the result of whether the specified suite will run on this shard
+    * or not.
+    */
   def check(suiteName: String, shardContext: ShardContext): ShardResult
 
   /** Determines whether the specified suite will run on this shard or not. */
@@ -135,8 +142,6 @@ object ShardingAlgorithm {
     def check(suiteName: String, shardContext: ShardContext): ShardResult =
       bucketMap.get(suiteName) match {
         case Some(bucketIndex) =>
-//          shardContext.logger.info(s"Balanced $specName")
-
           ShardResult(Some(bucketIndex))
 
         case None =>