As with any modern language, you can extend your code by using libraries, in Java, they are called dependencies.
You could manage your dependencies manually, by adding their jar files to the project. Or you can use a tool to help you do that.
There are two major tools for project and dependency management:
Our project is using Gradle.
Several logging frameworks are available in Java, such as Log4j, Logback and java.common.logging.
One of the popular Kotlin-specific logging frameworks is Kotlin-logging.
import mu.KLogging
object TemperatureConverter: KLogging() {
fun toCelsius(fahrenheit: Double): Double {
logger.info("Converting $fahrenheit Fahrenheit to Celsius")
return (fahrenheit - 32) * 5 / 9
}
fun toFahrenheit(celsius: Double): Double {
logger.info("Converting $celsius Celsius to Fahrenheit")
return celsius * 9 / 5 + 32
}
}
There are several logging levels, such as TRACE, DEBUG, INFO, WARN, ERROR and FATAL.
By setting the logging level, you can control the amount of information that is logged. For example, if you set the logging level to INFO, only messages with level INFO and higher will be logged.
Add a Gradle dependency for Kotlin-logging and use it in your project by adding the following to the build.gradle.kts file dependencies section, so it might look like:
dependencies {
implementation("org.slf4j:slf4j-api:2.0.7")
implementation("ch.qos.logback:logback-classic:1.4.11")
implementation("io.github.oshai:kotlin-logging-jvm:7.0.3")
testImplementation(kotlin("test"))
}
In your code, you add a logger by adding KotlinLogging.logger { }
and use it by calling
logger.info { "info message" },
logger.debug { "debug message" },
logger.error { "error message" },
etc.
import io.github.oshai.kotlinlogging.KotlinLogging
private val logger = KotlinLogging.logger { }
fun main() {
logger.info { "Hello, World!" }
}
Include this file in your src/main/resources folder.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss} %highlight(%-5level) [%thread] %cyan(%logger{1}) - %msg%n</pattern>
</encoder>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>INFO</level>
</filter>
</appender>
<root level="TRACE">
<appender-ref ref="STDOUT" />
</root>
<logger name="*" level="DEBUG"/>
</configuration>
It is an essential skill of any software developer.
Usually, an IDE (such as IntelliJ IDEA) will have a debugger built in, which will allow you to step through your code, inspect variables and evaluate expressions to see what the program is doing, while it is executing
object TemperatureConverter: KLogging() {
/**
* Converts temperature value given in Fahrenheit to Celsius
*
* @param fahrenheit temperature value in Fahrenheit
* @return temperature value in Celsius
* @see [Fahrenheit](https://en.wikipedia.org/wiki/Fahrenheit)
* @see [Celsius](https://en.wikipedia.org/wiki/Celsius)
*/
fun toCelsius(fahrenheit: Double): Double {
logger.info("Converting $fahrenheit Fahrenheit to Celsius")
return (fahrenheit - 32) * 5 / 9
}
/**
* Converts temperature value given in Celsius to Fahrenheit
*
* @param celsius temperature value in Celsius
* @return temperature value in Fahrenheit
* @see [Fahrenheit](https://en.wikipedia.org/wiki/Fahrenheit)
* @see [Celsius](https://en.wikipedia.org/wiki/Celsius)
*/
fun toFahrenheit(celsius: Double): Double {
logger.info("Converting $celsius Celsius to Fahrenheit")
return celsius * 9 / 5 + 32
}
}
For details, see Javadoc Tool
What is quality, and how does it relate to testing and the product?
Is a product considered good quality if it contains no errors?
A product is something someone desires because it satisfies their needs.
We can view the quality of a product from two perspectives:
What the product does = external quality.
&
How it does it = internal quality.
Regression == in terms of testing, regression is a defect unintentionally introduced by a change into a previously working part of software.
There are two types of testing based on the testers knowledge of the system internal structure/design/implementation.
Test ID: 1234
Title: User is blocked after 3 failed login attempts
Pre-Conditions:
User test.user@harbourspace.com exists and is not blocked.
Test Steps:
| # | Step | Expected Result |
| 1. | Open the login page | Login page is shown |
| 2. | Enter the username test.user@harbourspace.com and password invalid | User is not logged in, is informed of invalid credentials. Password field is nullified. |
| 3. | Enter the password invalid again | User is not logged in, is informed of invalid credentials. Password field is nullified. |
| 4. | Enter the password invalid again | User is not logged in, is informed that their account was locked. |
Expected Result:
User is not logged in and their account is locked.
Test design techniques are techniques used to design tests.
They are used to ensure adequate test coverage, optimize the number of tests, maximize the effectiveness of tests and manage risks.
Test coverage is a measure of the degree to which the source code of a program has been tested.
It is usually expressed as a percentage of code that has been executed by the test suite.
Different metrics are used to measure test coverage, such as function coverage, statement coverage, branch coverage, etc.
Remember that exhaustive testing is impossible!
In this example, there are 4 partitions of equivalent data. In theory, any test case from a partition should yield the same result.
For example these sets of values belong to the same partitions:
-275.0, -1.0, 10.0, 100.1
-280.0, -100.0, 99.0, 101.0
There are 3 boundary values in this example: -273.15, 0.0 and 100.0
Equivalence partitioning and boundary value analysis are often used together.
| Conditions | Test 1 | Test 2 | Test 3 | Test 4 |
| User exists | YES | YES | NO | YES |
| Password correct | YES | NO | - | YES |
| User blocked | NO | NO | NO | YES |
| Actions | Test 1 | Test 2 | Test 3 | Test 4 |
| Allow access | YES | NO | NO | NO |
| Block user | NO | YES | - | - |
| Color | Shape | Size | |
| Test 1 | red | square | small |
| Test 2 | red | circle | large |
| Test 3 | green | square | large |
| Test 4 | green | circle | small |
This is an orthogonal array of 3 factors with 2 levels each - L4(2^3).
It is based on the observation that most faults are caused by interactions of at most two factors.
This testing technique is rarely implemented "by hand", but usually with the help of specialized tools.
There are techniques that extend all-pairs testing to more than two factors, such as all-tuples testing, but these techniques are not widely used, because they generate very large number of test cases with insignificant added benefit.
Another important role of unit testing is documentation. By writing unit tests, we document the behavior we intended, so that when we, or someone else wants to make changes in the software, they will understand how the software was supposed to work.
The reason TDD is development technique and not a test technique is because by writing tests first, you are making code testable by design. Well-testable code usually directly correlates with code quality and therefore overall software quality.
Integration testing can be ...
Integration tests are typically more costly to run than unit tests, because they require more resources and are usually slower. They may also be less reliable.
On the other hand, they provide more information about the system as a whole, and may uncover problems that are not visible at the unit level.
Main features of a unit testing framework include:
There are several options available for Kotlin, such as JUnit, which is a Java framework, and Kotest.
We will use Kotest in this course, but the concepts that we will learn with generally apply to all unit testing frameworks.
It is actually based on the JUnit, so it can be used alongside JUnit tests.
It supports various styles of testing, such as behavior-driven development (BDD), data-driven testing, and property-based testing.
There are several styles of writing tests in Kotest, which you can chose by extending a specific Kotest class, or using a specific function.
class ExampleTest : FunSpec({
test("test name") {
// test code
}
})
A more realistic test might look like this:
package com.motycka.edu.lesson04
import com.motycka.edu.lesson04.Coffee.*
import io.kotest.core.spec.style.FunSpec
import io.kotest.core.spec.style.ShouldSpec
import io.kotest.core.spec.style.StringSpec
import io.kotest.matchers.shouldBe
class PriceCalculatorTest : FunSpec({
val priceCalculator = PriceCalculator(applyDiscount = 4)
test("should apply discount for 4 coffees - cheapest one free") {
val order = listOf(ESPRESSO, ESPRESSO, CAPPUCCINO, AMERICANO)
val expectedTotal = order.sumOf { it.price } - AMERICANO.price
priceCalculator.calculatePrice(order).shouldBe(expectedTotal)
}
})
Kotest supports several styles of writing tests, such as:
class ExampleFunTest : FunSpec({
test("test name") {
// test code
}
})
class ExampleStringTest : StringSpec({
"test name" {
// test code
}
})
class ExampleTest : ShouldSpec({
should("test name") {
// test code
}
})
number.shouldBeGreaterThan(3.0)
number.shouldBeGreaterThanOrEqualTo(3.15)
number.shouldBeLessThan(4.0)
number.shouldBeBetween(a = 3.0, b = 4.0, tolerance = 0.01)
string.shouldBe("Hello, Kotest!")
string.shouldNotBeNull()
string.shouldNotBeEmpty()
list.shouldBe(listOf(1, 2, 3, 4, 5))
list.shouldHaveSize(5)
list.shouldNotBeEmpty()
list.shouldBeSorted()
list.shouldBeMonotonicallyIncreasing()
list.shouldContain(2)
list.shouldContainAll(1, 2, 3)
booleanValue.shouldBeTrue()
booleanValue.shouldBeFalse()
The value of tests is that they give us feedback during development. There are few rules that help us make sure that the feedback we get from tests is accurate and reliable.
Kotest supports nesting of tests within contexts. This allows you to logically group tests together and provide more context and better readability in test results.
class PriceCalculatorTests: StringSpec({
"Price Calculator" {
"should not allow discount less than 2" {
val exception = kotlin.runCatching { PriceCalculator(applyDiscount = 1) }
exception.isFailure shouldBe true
}
}
"when calculating with discount on every 4th coffee" {
val priceCalculator = PriceCalculator(applyDiscount = 4)
"should apply no discount for 3 coffees" {
val order = listOf(ESPRESSO, CAPPUCCINO, AMERICANO)
val expectedTotal = order.sumOf { it.price }
priceCalculator.calculatePrice(order).shouldBe(expectedTotal)
}
"should apply discount for 4 coffees - cheapest one is free" {
val order = listOf(ESPRESSO, ESPRESSO, CAPPUCCINO, AMERICANO)
val expectedTotal = order.sumOf { it.price } - AMERICANO.price
priceCalculator.calculatePrice(order).shouldBe(expectedTotal)
}
"should apply discount for 9 coffees - cheapest two are free" {
val order = listOf(
ESPRESSO,
CAPPUCCINO, CAPPUCCINO, CAPPUCCINO,
FLAT_WHITE, FLAT_WHITE,
LATTE, LATTE,
AMERICANO
)
val expectedTotal = order.sumOf { it.price } - AMERICANO.price - ESPRESSO.price
priceCalculator.calculatePrice(order).shouldBe(expectedTotal)
}
}
})
To make understanding test results easier, we should choose the right assertion methods that will give us the most information about the failure. All of these assertions would work, but the first two provide much clearer information
Example 1
number.shouldBe(100.0)
expected:<100.0> but was:<99.0>
Expected :100.0
Actual :99.0
string.shouldBe("Hello, Kotlin!")
expected:<"Hello, Kotlin!"> but was:<"Hello, Kotest!">
Expected :"Hello, Kotlin!"
Actual :"Hello, Kotest!"
Example 2
(string == "Hello, Kotlin!").shouldBeTrue()
Expected :true
Actual :false
Several annotations can be used to control the test lifecycle. They might be specific to the test style you chose, but in general they look like this.
These annotations are:
class ExampleSpec : FunSpec({
beforeTest {
println("this block executes before each test")
}
afterTest {
println("this block executes after each test")
}
beforeSpec {
println("this block executes before spec")
}
afterSpec {
println("this block executes after spec")
}
test("test name") {
// test code
}
})
Here is an example of a simple JUnit test written in Kotlin.
import org.junit.jupiter.api.Assertions
import org.junit.jupiter.api.DisplayName
import org.junit.jupiter.api.Test
// By convention the name of the test class should be the name of the class under test + "Test"
class TemperatureConverterTest {
@Test
@DisplayName("should convert Celsius to Fahrenheit - 0C = 32F")
fun testConvertCelsiusToFahrenheit() {
Assertions.assertEquals(32.0, TemperatureConverter.toFahrenheit(0.0));
}
// different style of test name
@Test
fun `should convert Fahrenheit to Celsius - 32F = 0C`() {
Assertions.assertEquals(0.0, TemperatureConverter.toCelsius(32.0));
}
}
import org.junit.jupiter.api.AfterAll
import org.junit.jupiter.api.AfterEach
import org.junit.jupiter.api.Assertions
import org.junit.jupiter.api.BeforeAll
import org.junit.jupiter.api.BeforeEach
import org.junit.jupiter.api.DisplayName
import org.junit.jupiter.api.Test
class TemperatureConverterTest {
@BeforeEach
fun beforeEach() {
println("This runs before each test");
}
@AfterEach
fun afterEach() {
println("This runs after each test");
}
@Test
@DisplayName("should convert Celsius to Fahrenheit - 0C = 32F")
fun testConvertCelsiusToFahrenheit() {
Assertions.assertEquals(32.0, TemperatureConverter.toFahrenheit(0.0));
}
// different style of test name
@Test
fun `should convert Fahrenheit to Celsius - 32F = 0C`() {
Assertions.assertEquals(0.0, TemperatureConverter.toCelsius(32.0));
}
companion object {
@BeforeAll
@JvmStatic
fun setUp() {
println("This runs once before all tests");
}
@AfterAll
@JvmStatic
fun tearDown() {
println("This runs once after all tests");
}
}
}
Introduction to application development in Ktor