Wzorzec projektowy ObjectMother to technika używana w testach jednostkowych, która pomaga w generowaniu obiektów testowych. W tym wpisie przedstawię, jak można zastosować ten wzorzec w języku Kotlin.
Wzorzec najlepiej sprawdza się w dużych projektach z wieloma testami, które używają podobnych obiektów.
data class Customer(val id: Int, val name: String, val email: String)
data class Product(val id: Int, val name: String, val price: Double)
data class Order(val id: Int, val customer: Customer, val products: List<Product>)
package pro.adamski.objectMother
import kotlin.random.Random
object ObjectMother {
fun customer(
id: Int = Random.nextInt(),
name: String = "John Doe${Random.nextInt()}",
email: String = "info-${Random.nextInt()}@example.com"
): Customer {
return Customer(id, name, email)
}
fun product(
id: Int = Random.nextInt(),
name: String = "The ${Random.nextInt()}th laptop",
price: Double = Random.nextDouble(1000.0, 5000.0)
): Product {
return Product(id, name, price)
}
fun order(
id: Int = Random.nextInt(),
customer: Customer = customer(),
products: List<Product> = listOf(product())
): Order {
return Order(id, customer, products)
}
fun largeOrder(id: Int = Random.nextInt(), customer: Customer = customer()): Order {
val products = List(100) { product(id = it, name = "Product$it") }
return Order(id, customer, products)
}
}
package pro.adamski.objectMother;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
public class ObjectMotherJava {
private static final Random random = new Random();
public static CustomerBuilder customer() {
return new CustomerBuilder()
.withId(random.nextInt())
.withName("John Doe" + random.nextInt())
.withEmail("info-" + random.nextInt() + "@example.com");
}
public static ProductBuilder product() {
return new ProductBuilder()
.withId(random.nextInt())
.withName("The " + random.nextInt() + "th laptop")
.withPrice(random.nextDouble() * (5000.0 - 1000.0) + 1000.0);
}
public static OrderBuilder order() {
return new OrderBuilder()
.withId(random.nextInt())
.withCustomer(customer().build())
.addProduct(product().build());
}
public static Order largeOrder() {
OrderBuilder orderBuilder = new OrderBuilder()
.withId(random.nextInt())
.withCustomer(customer().build());
for (int i = 0; i < 100; i++) {
orderBuilder.addProduct(product().withId(i).withName("Product" + i).build());
}
return orderBuilder.build();
}
}
Pełny kod fluent builderami na GitHub
package pro.adamski.objectMother
import org.assertj.core.api.Assertions.assertThat
import org.junit.jupiter.api.Test
class OrderTest {
@Test
fun testCustomOrder() {
// Given
val customProduct = ObjectMother.product(name = "Custom Laptop", price = 2000.0)
// When
val customOrder = ObjectMother.order(products = listOf(customProduct))
// Then
assertOrderProduct(customOrder.products.first(), "Custom Laptop", 2000.0)
}
@Test
fun testRandomLargeOrder() {
// When
val largeOrder = ObjectMother.largeOrder()
// Then
assertOrderProducts(largeOrder, 100, 1000.0..5000.0)
}
@Test
fun testCustomOrderJava() {
// Given
val customProduct = ObjectMotherJava.product().withName("Custom Laptop").withPrice(2000.0).build()
// When
val customOrder = ObjectMotherJava.order().withProducts(listOf(customProduct)).build()
// Then
assertOrderProduct(customOrder.products.first(), "Custom Laptop", 2000.0)
}
@Test
fun testRandomLargeOrderJava() {
// When
val largeOrder = ObjectMotherJava.largeOrder()
// Then
assertOrderProducts(largeOrder, 100, 1000.0..5000.0)
}
private fun assertOrderProducts(
largeOrder: Order,
numberOfProducts: Int,
priceRange: ClosedFloatingPointRange<Double>
) {
assertThat(largeOrder.products).hasSize(numberOfProducts)
assertThat(largeOrder.products).allMatch {
it.price in priceRange
}
}
private fun assertOrderProduct(firstProduct: Product, name: String, price: Double) {
assertThat(firstProduct.name).isEqualTo(name)
assertThat(firstProduct.price).isEqualTo(price)
}
}
Wzorzec ObjectMother jest bardzo użyteczny, zwłaszcza w dużych projektach z rozbudowaną bazą testów. Pomaga w utrzymaniu czystego i efektywnego kodu testowego. W przypadku implementacji w Javie zastosowanie fluent builderów pozwala na jeszcze większą czytelność kodu testowego.
W ostatnio miałem okazje uczestniczyć w konferencji Confitura. Jedna z prezentacji okazała się szczególnie ciekawa.
Opis prezentacji:
Autor prezentacji: Piotr Stawirej
Zaprezentuję, jak można uprościć aplikację i umożliwić jej testowanie poprzez analizę napotkanych przypadków i zastosowanych rozwiązań. Skupimy się na niestandardowych przypadkach oraz często powtarzalnych sytuacjach, które występują podczas naszej pracy. Nauczymy się jak testować problematyczne klasy, integrację z bibliotekami, frameworkami i usługami zewnętrznymi, jak skutecznie używać zaślepek (fakes), co mockować, a czego nie, jak testować aplikacje wielowątkowe, jak przyspieszać testy integracyjne, jak testować kod zależny od czasu i działania bez widocznego efektu, jak testować tolerancję na błędy oraz jak ponownie wykorzystać akceptacyjne testy jednostkowe jako testy integracyjne lub API. Omówimy, dlaczego warto stosować Property Based Testing dla Value Object’ów, jak testować obiekty mutowalne, zapis (persistence), czy testować logowanie, jak testować kod asynchroniczny. Poznamy przydatne heurystyki testowania oraz alternatywę dla testów wydajnościowych.
Poniżej przedstawiam kilka moim zdaniem szczególnie istotnych aspektów przedstawionych w prezentacji.
Fake to implementacja prostego obiektu, która udaje funkcjonalność rzeczywistego obiektu, ale w sposób uproszczony. Fake są często tworzone ręcznie jako proste implementacje interfejsów lub klas, które na potrzeby testów mają zachowywać się podobnie do prawdziwych obiektów.
Mock to obiekt, który symuluje zachowanie innych obiektów w systemie, umożliwiając kontrolowanie i sprawdzanie interakcji. Mocki są często tworzone przy użyciu bibliotek (np. Mockito) i pozwalają programistom na kontrolowanie, jak obiekty testowane współdziałają z innymi zależnościami.
Jednym z ciekawych problemów omawianych podczas niedawnej prezentacji był przypadek testowy, który restartował kontekst Springa przed każdą metodą testową, co skutkowało znacznym wydłużeniem czasu wykonania testów. Aby temu zaradzić, warto poszukać bardziej efektywnych sposobów przygotowania się do testów. W opisanym przykładzie zamiast restartu zastosowano metodę setup, która usuwała wszystkie wiersze z bazy danych, skracając czas wykonania z 27 sekund do kilkuset milisekund. Ta optymalizacja znacząco poprawiła cały proces testowania.
Innym interesującym podejściem podkreślonym w prezentacji było stosowanie implementacji Fake jako alternatywy dla prostych Mocków. Implementacje Fake mają przewagę ponownego wykorzystania w wielu testach. Przykładem tego podejścia był proste repozytorium oparte na mapie.
Niezwykle interesującym przypadkiem omówionym podczas prezentacji było wykorzystanie testów jednostkowych jako testów na wyższym poziomie. Proces ten polegał na wyodrębnieniu interfejsu z komponentu odpowiedzialnego za przypadki użycia (np. serwisu aplikacyjnego w kontekście Domain-Driven Design). Następnie napisano test jednostkowy, który korzystał tylko z Mocków lub implementacji Fake, aby sprawdzić funkcjonalność aplikacji. Ten sam test mógł zostać skonfigurowany tak, aby korzystał z prawdziwych implementacji, na przykład repozytorium osadzonego lub opartego na kontenerach testowych. Co więcej, ten sam test mógł być rozszerzony o testowanie interfejsu API poprzez zastąpienie komponentu implementującego przypadki użycia klientem API lub rozwiązaniem opartym na Selenium.
Czasami w testach można napotkać wyniki, które są trudne do obserwacji, co może prowadzić do niejasności lub błędnego przypuszczenia, że oczekiwane zachowanie nie zostało zaimplementowane. Jest to szczególnie trudne w przypadku podejścia Test-Driven Development (TDD). Aby temu zaradzić, warto jawnie uwzględnić oczekiwane zachowanie w teście, nawet jeśli nie jest ono bezpośrednio obserwowalne.
Testowanie oprogramowania może być wyzwaniem, ale zastosowanie odpowiednich strategii może znacznie poprawić efektywność i jakość procesu testowania. Optymalizacja czasu wykonania testów, wykorzystanie implementacji Fake, testowanie na różnych poziomach abstrakcji i zapewnienie obserwowalności wyników to tylko kilka z wielu przydatnych strategii. Mając świadomość tych wyzwań i stosując odpowiednie metody, programiści mogą skutecznie radzić sobie z trudnościami związanymi z testowaniem i dostarczać lepsze oprogramowanie.
]]>W pełni funkcjonalny serwer możemy utworzyć za pomocą tylko jednego pliku server.groovy.
Dodać plik server.groovy
@Grapes([
@GrabConfig(systemClassLoader = true),
@Grab(group = 'org.springframework.boot', module = 'spring-boot-starter-web', version = '2.2.6.RELEASE'),
@GrabExclude(group = 'org.springframework.boot', module = 'spring-boot-starter-tomcat'),
@Grab(group = 'org.springframework.boot', module = 'spring-boot-starter-undertow', version = '2.2.6.RELEASE')
])
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.web.bind.annotation.*
import org.springframework.boot.SpringApplication
/**
* @author akrystian
*/
@SpringBootApplication
@RestController
class App {
@RequestMapping("/")
String simpleEndpoint() {
return "Hello!!"
}
}
static void main(String[] args) {
SpringApplication.run(App.class, args)
}
groovy server.groovy
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.2.6.RELEASE)
2020-04-04 02:28:52.463 INFO 32601 --- [ main] groovy.ui.GroovyMain : Starting GroovyMain v2.5.5 on Legion with PID 32601 (/home/krystian/.sdkman/candidates/groovy/current/lib/groovy-2.5.5.jar started by krystian in /home/krystian/IdeaProjects/code.conference.site)
2020-04-04 02:28:52.469 INFO 32601 --- [ main] groovy.ui.GroovyMain : No active profile set, falling back to default profiles: default
2020-04-04 02:28:53.391 WARN 32601 --- [ main] io.undertow.websockets.jsr : UT026010: Buffer pool was not set on WebSocketDeploymentInfo, the default pool will be used
2020-04-04 02:28:53.411 INFO 32601 --- [ main] io.undertow.servlet : Initializing Spring embedded WebApplicationContext
2020-04-04 02:28:53.411 INFO 32601 --- [ main] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 871 ms
2020-04-04 02:28:53.586 INFO 32601 --- [ main] o.s.s.concurrent.ThreadPoolTaskExecutor : Initializing ExecutorService 'applicationTaskExecutor'
2020-04-04 02:28:53.716 WARN 32601 --- [ main] .b.a.g.t.GroovyTemplateAutoConfiguration : Cannot find template location: classpath:/templates/ (please add some templates, check your Groovy configuration, or set spring.groovy.template.check-template-location=false)
2020-04-04 02:28:53.859 INFO 32601 --- [ main] io.undertow : starting server: Undertow - 2.0.30.Final
2020-04-04 02:28:53.866 INFO 32601 --- [ main] org.xnio : XNIO version 3.3.8.Final
2020-04-04 02:28:53.873 INFO 32601 --- [ main] org.xnio.nio : XNIO NIO Implementation Version 3.3.8.Final
2020-04-04 02:28:53.994 INFO 32601 --- [ main] o.s.b.w.e.u.UndertowServletWebServer : Undertow started on port(s) 8080 (http) with context path ''
2020-04-04 02:28:53.998 INFO 32601 --- [ main] groovy.ui.GroovyMain : Started GroovyMain in 1.996 seconds (JVM running for 4.051)
2020-04-04 02:29:32.110 INFO 32601 --- [ XNIO-1 task-1] io.undertow.servlet : Initializing Spring DispatcherServlet 'dispatcherServlet'
2020-04-04 02:29:32.110 INFO 32601 --- [ XNIO-1 task-1] o.s.web.servlet.DispatcherServlet : Initializing Servlet 'dispatcherServlet'
2020-04-04 02:29:32.118 INFO 32601 --- [ XNIO-1 task-1] o.s.web.servlet.DispatcherServlet : Completed initialization in 8 ms
> curl -i http://localhost:8080/
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/plain;charset=UTF-8
Content-Length: 7
Date: Sat, 04 Apr 2020 00:42:57 GMT
Hello!!%
W tym wpisie postaram się zdefiniować dlaczego warto uczestniczyć w coderetreat.
Ja byłem już na dwóch takich warsztatach (cztery i pięć lat temu). Z każdego wyniosłem wiele, ale jedną zapamiętałem najbardziej. Był to czas kiedy zaczynałem moją karierę programisty, pisząc w NetBeans. Zasiadłem w parze z programistą zdecydowanie bardziej zaawansowanym ode mnie. To była 4 iteracja, więc problem już był raczej rozpracowany (implementacja oparta o zbiór aktywnych komórek, a nie żadna tablica dwuwymiarowa z booleanami). Z tych czterdziestu pięciu minut wyniosłem:
Warsztat składa się z 5 iteracji. Każda kolejna iteracja wprowadza inne ograniczenia, które można wybrać (lista przykładowych). Podczas warsztatu zalecane jest przestrzeganie Test Driven Development i 4 zasad tworzenia oprogramowania.
Praktyczne zapoznanie z podejściem Test Driven Development. Programowanie z podziałem na fazy:
Podczas pracy w parach ważna jest współpraca z drugą osobą. Na początku trzeba ustalić wspólną koncepcję. Zdecydować o kolejności w jakiej będziemy implementować rozwiązanie problemu. Dodatkowo warto sobie wypracować model współpracy, bo ostatecznie kod trafia na jedną klawiaturę.
Można zobaczyć warsztat innej osoby, a także podzielić się swoim. Najczęściej na pierwszy ogień idą skróty klawiaturowe oraz ciekawe funkcjonalności IDE. Ale na drugim miejscu jest sposób tworzenia kodu oraz sposób rozwiązywania problemów.
Wymiana spostrzeżeń w retrospekcjach jest bezcenna. Najczęściej zadawane są trzy pytania:
Często większość osób zaczyna z różnymi implementacjami opartymi o dwuwymiarową tablicę. W kolejnych iteracjach rozwiązanie problemu kierowane jest w stronę bardziej optymalnego rozwiązania (dodatkowym aspektem tego jest mieszanie się osób w kolejnych iteracjach podczas programowania w parach).
Rozwiązywanie kilka razy tego samego problemu mogłoby się okazać niezbyt ciekawe. Na szczęście kolejne iteracje dodają inne ograniczenia w rozwiązaniu tego samego problemu. Weźmy trzy przykładowe:
Moim zdaniem ciężko znaleźć bardziej wszechstronny warsztat, który zapewniałby wymianę wiedzy w tak krótkim czasie. Iteracyjny charakter i wymiana par ma na celu skomasować doświadczenia płynące od wielu osób z którymi można programować w parze. Dodatkowo retrospekcje całej grupy przynoszą często wiele nieoczekiwanych wniosków do których trudno dojść w pojedynczej parze.
]]>Kilka przydatnych stron gdzie można znaleźć najnowsze nowości ze świata IT.
Umożliwienie zestawienia połączenia https do niezaufanej usługi za pomocą aplikacji uruchomionej na maszynie wirtualnej java.
Często na etapie tworzenia usług mamy potrzebę do połączenia do usługi która jest udostępniona po protokole https, ale certyfikat takiej strony nie jest zaufany. Gdy uruchomimy taką w aplikacje na maszynie wirtualnej java która łączy się do niezaufanego adresu https to dostaniemy błąd.
Przykładowy skrypt w groovym.
def content = new URL("https://self-signed.badssl.com/").text
println content
~ groovy scratch_1.groovy
Caught: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at scratch_1.run(scratch_1.groovy:1)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
... 1 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
... 1 more
Aby maszyna wirtualna pozwoliła się połączyć do niezaufanej usługi https wymagane jest:
Przydatny może się okazać poniższy skrypt (addToJavaKeystore.sh):
#!/bin/bash
set -e
set -u
command_exists ()
{
type "$1" >/dev/null 2>&1 || { echo "I require ${1} but it's not installed. Aborting." >&2; exit 1; }
}
command_exists openssl
command_exists sed
HOST=${1}
PORT=443
JAVA_HOME=${2}
KEYSTORE_FILE=${JAVA_HOME}/jre/lib/security/cacerts
KEYSTORE_PASS=changeit
KEYTOOL_FILE=${JAVA_HOME}/bin/keytool
CERT_FILE=${HOST}.cert
# save the SSL certificate to file
openssl s_client -connect ${HOST}:${PORT} </dev/null \
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > ${CERT_FILE}
# create a keystore and import certificate
${KEYTOOL_FILE} -import -noprompt -trustcacerts \
-alias ${HOST} -file ${CERT_FILE} \
-keystore ${KEYSTORE_FILE} -storepass ${KEYSTORE_PASS}
# verify we have got it.
${KEYTOOL_FILE} -list -v -keystore ${KEYSTORE_FILE} -storepass ${KEYSTORE_PASS} -alias ${HOST}
# remove cert file
rm -f ${CERT_FILE}
Po uruchomieniu skryptu dla domeny self-signed.badssl.com
sudo ./addToJavaKeystore.sh self-signed.badssl.com $JAVA_HOME
~ sudo ./addToJavaKeystore.sh self-signed.badssl.com $JAVA_HOME
depth=0 C = US, ST = California, L = San Francisco, O = BadSSL, CN = *.badssl.com
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = BadSSL, CN = *.badssl.com
verify error:num=10:certificate has expired
notAfter=Aug 8 21:17:05 2018 GMT
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = BadSSL, CN = *.badssl.com
notAfter=Aug 8 21:17:05 2018 GMT
verify return:1
DONE
Certificate was added to keystore
Alias name: self-signed.badssl.com
Creation date: 2019-10-09
Entry type: trustedCertEntry
Owner: CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US
Issuer: CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US
Serial number: 86fb4dc8e5dd0f18
Valid from: Mon Aug 08 23:17:05 CEST 2016 until: Wed Aug 08 23:17:05 CEST 2018
Certificate fingerprints:
MD5: 46:10:F4:1F:93:A3:EE:58:E0:CC:69:BE:1C:71:E0:C0
SHA1: 64:14:50:D9:4A:65:FA:EB:3B:63:10:28:D8:E8:6C:95:43:1D:B8:11
SHA256: 28:C9:E8:BA:A6:03:EE:94:00:2E:CA:CD:37:C1:50:91:DC:A6:E1:AC:8E:D4:29:E3:11:89:7C:6C:72:20:34:B0
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3
Extensions:
#1: ObjectId: 2.5.29.19 Criticality=false
BasicConstraints:[
CA:false
PathLen: undefined
]
#2: ObjectId: 2.5.29.17 Criticality=false
SubjectAlternativeName [
DNSName: *.badssl.com
DNSName: badssl.com
]
Wykonanie skyptu po dodaniu domeny do keystore:
~ groovy scratch_1.groovy
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="shortcut icon" href="/icons/favicon-red.ico"/>
<link rel="apple-touch-icon" href="/icons/icon-red.png"/>
<title>self-signed.badssl.com</title>
<link rel="stylesheet" href="/style.css">
<style>body { background: red; }</style>
</head>
<body>
<div id="content">
<h1 style="font-size: 12vw;">
self-signed.<br>badssl.com
</h1>
</div>
</body>
</html>
Udało się połączyć do niezaufanej usługi https. :)
]]>Czy można stworzyć usługę w 5 min? Można.
gradle init --type java-application
build.gradleplugins {
id 'java'
id "org.springframework.boot" version "2.0.2.RELEASE"
}
dependencies {
compile 'org.springframework.boot:spring-boot-starter-web:2.0.2.RELEASE'
testCompile 'junit:junit:4.12'
}
repositories {
jcenter()
}
Usunąć wszystkie pliki *.java z katalogu src i test.
Dodać klasę aplikacji
package pro.adamski;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
/**
* @author akrystian
*/
@SpringBootApplication
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class, args);
}
}
package pro.adamski.endpoints;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
/**
* @author akrystian
*/
@RestController
public class SimpleEndpoint {
@RequestMapping("/")
public String simpleEndpoint(){
return "Hello!!";
}
}
./gradlew bootJar
java -jar ./build/libs/microBootApp.jar
curl -i http://localhost:8080/
HTTP/1.1 200
Content-Type: text/plain;charset=UTF-8
Content-Length: 7
Date: Thu, 31 May 2018 19:33:41 GMT
Hello!!%
Instalacja oprogramowania na Windowsie zajmuje dużo czasu i jest często zagmatwana. Z pomocą mogą przyjść narzędzia automatyzujące ten proces.
apt-get znanego z Ubuntu.