Devoxx 2023 - Your Tests also need some Architecting

Transcript

1. 1 Jonas Geiregat Your tests also need some architecting @jonas_grgt https://jonasg.io
3. No tests
4. The early days define you
5. Prevent regression
6. Refactor freely and in a safe way
7. Make our systems evolvable at a steady pace SPEED TIME SPEED TIME
8. Tests are executable pieces of documentation
9. Guide our design
10. Continuously release with confidence
11. The reality of tests - Brittle - Complex - Hard to maintain - Did not guide - Cryptic - Slow - Skipped
12. The benefits of tests should outweigh the cost of writing, running and maintaining them
13. “Architecture is about the important stuff. Whatever that is.” -- Ralph Johnson
14. Architecture is about making tradeoffs with the right context.
15. “Architects are like sherpas that guide” -- Martin Fowler - Who Needs an Architect?
16. How did we end up here?
17. You do not only write a test in the current moment for the current moment
18. Why do we write tests ?
19. - Requirements - Integrations - Security - Technology - Data Formats - Deployments - People - Organizations We write test to cope with change
20. The ability to change is the key characteristic of software Tests are change enablers
21. Other things are also important but if your software can change you can always: make it faster make it more secure make it more resilient make it more user-friendly
22. What do we test ? What is the system under test ?
23. Engineers love solving problems, that have zero business value because it’s considered fun. What do we write code for ?
24. “The trigger for writing a test is not a new class nor a new public method” -- Ian Cooper - TDD, Where Did It All Go Wrong
25. The trigger is a behaviour
26. Test your behavioral contract whatever that means technically
27. BDD is a misunderstood reaction to the misconceptions of TDD.
28. So you want us to only write integration tests ? -- Fellow developers - coffee machine
29. unit tests end to end tests integration tests slow / expensive fast / cheap Does the classical testing Pyramid still stand ?
30. The type of test: is how you are testing It is a technical detail, that is seldom relevant - unit - integration - acceptance - etc ..
31. - an integration - a behavior - an implementation detail What are you testing Is much more relevant
32. integrated test impl. detail test behavior / feature / use-case test Testing Honeycomb static
33. Requirement: An email notification should be sent to the receiver once an invoice has been paid Defined by the EmailService interface Implemented by the SesEmailService
34. class XjxMapper { public <T> T read(String document, Class<T> clazz)
35. class XjxMapper { public <T> T read(String document, Class<T> clazz)
36. Wim Delvoye Cloaca
38. So how do we put this all into code ?
39. Test should not be viewed in the same manner one views production code. It’s a different context. Different rules are at play.
40. Avoid abstractions
41. Keep your readers in your test method Minimize setup and tear-down logic to only the technical
42. Cyclomatic complexity of a test should be 1
43. Classic test naming convention class InvoiceServiceTest { class SesEmailServiceTest { VS Test naming convention based on requirement/feature/behavior class PayInvoiceFeatureTest { class MarkInvoiceAsProcessedFeatureTest { class CreateInvoiceTemplateFeatureTest { class ProcessInvoiceFeatureTest { class AddInvoiceLineFeatureTest {
44. Do not communicate what you are testing @Test void testExpireInvoice() { @Test void addPineappleToppingToPizzaTest() {
45. Don’t communicate what you are testing but why you need a test The why captures the behaviour
46. The why @Test void testExpireInvoice() { @Test void unExpiredInvoice_shouldExpireAutomatically_after30DaysAfterPublicationDate() { @Test void addPineappleToppingToPizzaTest() { @Test void pineappleIsAnIllegalTopping_andShouldPreventTheCookFromAddingIt() {
47. Avoid giving examples
48. @Test void shouldConsider_abc_asAWeakPassword() { @Test void shouldConsider_abc_asATooShortPassword() { Examples of tests giving an example
49. @Test void shouldConsider_abc_asAWeakPassword() { @Test void shouldConsider_abc_asATooShortPassword() { Examples of tests giving an example
50. @Test void shouldConsiderPasswordsTooShort_whenHavingALengthOf_8_orLess() { @Test void minimumLengthOfAPasswordIs_8() { Focus on describing the behavior
51. To document is to communicate clearly Embrace magic numbers
52. var vatAmount = vatCalculator.getVatAmount(Percentage.valueOf(VAT_PERCENTAGE), Amount.eur(GROSS_PRICE)); assertThat(vatAmount).isEqualTo(Amount.eur(EXPECTED_AMOUNT)) Test that does not communicate or documents clearly
53. var vatAmount = vatCalculator.getVatAmount(Percentage.valueOf(21), Amount.eur(121)); assertThat(vatAmount).isEqualTo(Amount.eur(21)) Let your test document the full story by avoiding layers or abstractions
54. Address billingAddress = new Address.Builder() .streetAddress("123 Main St") .city("Anytown") .state("CA") .zipCode("12345") .country(Country.US) .build(); Address shippingAddress = new Address.Builder() .streetAddress("456 Oak Ave") .city("Othertown") .state("CA") .zipCode("67890") .country(Country.US) .build(); List<InvoiceItem> items = new ArrayList<>(); items.add(new InvoiceItem("Product A", 100.00, Tax.vatPercentage(21))); items.add(new InvoiceItem("Product B", 100.00, Tax.vatPercentage(21))); Customer customer = new Customer.Builder() .name("John Doe") .email("john.doe@example.com") .phoneNumber("555-123-4567") .build(); Invoice invoice = new Invoice.Builder() .invoiceNumber("001") .customer(customer) .billingAddress(billingAddress) .shippingAddress(shippingAddress) .invoiceDate(LocalDate.now()) .items(items) .build(); var amount = invoice.getVatAmount(); assertThat(amount).isEqualTo(Amount.EUR(42))
55. Given When Then Arrange Act Assert
56. // given Address billingAddress = new Address.Builder() .streetAddress("123 Main St") .city("Anytown") .state("CA") .zipCode("12345") .country(Country.USA) .build(); Address shippingAddress = new Address.Builder() .streetAddress("456 Oak Ave") .city("Othertown") .state("CA") .zipCode("67890") .country(Country.USA) .build(); List<InvoiceItem> items = new ArrayList<>(); items.add(new InvoiceItem("Product A", 100.00, Tax.vatPercentage(21))); items.add(new InvoiceItem("Product B", 100.00, Tax.vatPercentage(21))); Customer customer = new Customer.Builder() .name("John Doe") .email("john.doe@example.com") .phoneNumber("555-123-4567") .build(); Invoice invoice = new Invoice.Builder() .invoiceNumber("001") .customer(customer) .billingAddress(billingAddress) .shippingAddress(shippingAddress) .invoiceDate(LocalDate.now()) .items(items) .build(); // when var amount = invoice.getVatAmount(); // then assertThat(amount).isEqualTo(Amount.EUR(42))
57. Object Mother https://www.jonasg.io/posts/object-mother
58. InvoiceMother.validInvoice() <InvoiceMother.Builder> .withInvoiceItems( new InvoiceItem("Product A", Amount.EUR(100), Tax.vatPercentage(21)), new InvoiceItem("Product B", Amount.EUR(100), Tax.vatPercentage(21))) .build(); <Invoice> Emphasize what matters and hide the irrelevant parts returns a prefilled builder that allows you to override what is relevant
59. InvoiceMother.validInvoice(); InvoiceMother.validInvoiceWithUSShippingAddress(); InvoiceMother.validInvoiceFromYesterday(); InvoiceMother.validInvoiceWithInvoiceLines(10); InvoiceMother.validInvoice() <InvoiceMother.Builder> .withInvoiceItems( new InvoiceItem("Product A", Amount.EUR(100), Tax.vatPercentage(21)), new InvoiceItem("Product B", Amount.EUR(100), Tax.vatPercentage(21))) .build(); <Invoice> Limit your factory methods, override what matters with setters InvoiceMother.validInvoice() .withShippingAddress(address -> address.country(Country.US)) .build() Emphasize what matters and hide the irrelevant parts
60. //given var invoice = InvoiceMother.validInvoice() .withInvoiceItems( new InvoiceItem("Product A", Amount.EUR(100), Tax.vatPercentage(21)), new InvoiceItem("Product B", Amount.EUR(100), Tax.vatPercentage(21))) .build(); // when var amount = invoice.getVatAmount(); // then assertThat(amount).isEqualTo(Amount.EUR(42)) Emphasize what matters and hide the irrelevant details
61. Change is inevitable that is why we test Behavior is what we test Accepting that tests live in a different context is how we test
62. Test and production code should be equal citizens looked at from different context with equal architectural rights cared for equally equally important
63. Test are actually more important than production code
64. 64 Jonas Geiregat Thanks for listening @jonas_grgt https://www.jonasg.io Scan me for the slides