Gradle projects and boundary tests

A growing report program needs repeatable builds and behavioural tests. Gradle configures compilation, dependencies and test tasks. Its Kotlin DSL build files describe the build; they are not ordinary application source that belongs inside main.

Create a Kotlin/JVM project using the current official project instructions and its generated Gradle wrapper. Run ./gradlew test on suitable shells or gradlew.bat test on Windows. Kotlin.test supplies assertions for configured tests; the complete standalone example below uses check to demonstrate expectations without a test-library dependency.

Save the complete source as Main.kt and use the Kotlin/JVM environment. No separate input file is needed.

Kotlin/JVM · complete program

fun passed(score: Int): Boolean = score >= 75
fun main() {
  val cases = listOf(74 to false, 75 to true, 80 to true)
  for ((score, expected) in cases) check(passed(score) == expected)
  println("3 boundary checks passed")
}

Expected output

3 boundary checks passed

Follow the execution

The three checks cover below, at and above the pass threshold. A failed check throws instead of printing the success message. A package test suite should preserve those expectations while keeping input, calculations and console formatting separate.

Try this in the Kotlin compiler by pasting the complete program.

Keep reusable calculations separate from input and output. The Gradle wrapper selects the configured build-tool version; a build file supplies plugin and dependency settings. Follow current official compatibility guidance rather than copying arbitrary plugin versions into a new project.

Your task: Which case detects changing >= 75 into > 75?

Kotlin/JVM · complete program

fun passed(score: Int): Boolean = score >= 75
fun main() {
  val cases = listOf(74 to false, 75 to true, 80 to true)
  for ((score, expected) in cases) check(passed(score) == expected)
  println("3 boundary checks passed")
}

Worked answer

The case 75 with expected true detects the boundary error. Both rules still accept 80, so the distant value alone would miss it.

Use check for an intended state assertion, not as an unexplained substitute for a user-facing validation policy. Pin dependency versions and distinguish a missing build dependency from a logic failure. Coroutines require an explicit kotlinx-coroutines dependency.

The case 75 with expected true detects the boundary error. Both rules still accept 80, so the distant value alone would miss it. Use check for an intended state assertion, not as an unexplained substitute for a user-facing validation policy.

Further reading: official Kotlin documentation for this topic.