11/14/24 - Boston Java Users ACM Chapter - TDD: It's easier than you think!

Everyone loves writing tests, don’t they? How do you write good tests? What tools are available for you to write good tests?

In this session, I will dive into the many features of Quarkus that help developers write good tests. I will highlight some of the features of Quarkus, Dev Services and Continuous Testing, which help make testing easier. Additionally, I will live code some tests for common use cases developers encounter, including unit, integration, and “black box” testing of imperative and reactive RESTful and event-driven applications that use common services, such as databases and Kafka brokers. I will discuss techniques such as mocking, spying, and interaction-based testing/verification.

I'll even spend some time showing how IDE-based AI assistants can help!

Once you see how easy TDD really can be there isn't a reason to not do it!

Transcript

1. TDD It’s easier than you think! Eric Deandrea Sr. Principal Developer Advocate @ Red Hat @edeandrea
2. Who am I? • 25+ years software development experience ◦ ~11 years as DevOps Architect in financial services / insurance Java Champion • Contributor to Open Source Projects Quarkus Spring Boot, Spring Framework, Spring Security LangChain4j (& Quarkus LangChain4j) Wiremock Microcks • Build & deliver cloud-native development training programs • Published author • Avid boater & black belt in martial arts @edeandrea
3. https://red.ht/quarkus-spring-devs • Showcase & explain Quarkus, how it enables modern Java development & the Kubernetes- native experience • Introduce familiar Spring concepts, constructs, & conventions and how they map to Quarkus • Equivalent code examples between Quarkus and Spring as well as emphasis on testing patterns & practices 3
4. Why are we here today?
16. https://x.com/holly_cummins/status/1788138252572004441
18. But first, Some basics
20. end-to-end tests high realism high value
21. end-to-end tests unit tests low effort high realism high value
22. end-to-end tests unit tests integration tests low effort high realism high value
23. end-to-end tests unit tests integration tests low effort high realism
24. end-to-end tests unit tests integration tests low effort high realism tests with application server test REST endpoints tests with a database
26. Unit testing
27. Unit testing • Isolate a “unit” within the application as a standalone entity
28. Unit testing • Isolate a “unit” within the application as a standalone entity • Use mocking / spying to control dependencies of the unit during test
29. Unit testing • Isolate a “unit” within the application as a standalone entity • Use mocking / spying to control dependencies of the unit during test • Test all potential outcomes of a particular unit
30. Unit testing • Isolate a “unit” within the application as a standalone entity • Use mocking / spying to control dependencies of the unit during test • Test all potential outcomes of a particular unit • Should be run on all builds & before code is merged
31. Mocking
32. Mocking • Complete mock / “fake” object
33. Mocking • Complete mock / “fake” object • User must define interaction(s)
34. Mocking • Complete mock / “fake” object • User must define interaction(s) • Default behavior if not defined: do nothing
35. Mocking • Complete mock / “fake” object • User must define interaction(s) • Default behavior if not defined: do nothing • Can verify intended behaviors occurred after test (verification-based testing)
36. Spying
37. Spying • Partial mock / “real” object
38. Spying • Partial mock / “real” object • User doesn’t need to define interaction(s)
39. Spying • Partial mock / “real” object • User doesn’t need to define interaction(s) • Default behavior if not overridden: perform actual operation on object
40. Spying • Partial mock / “real” object • User doesn’t need to define interaction(s) • Default behavior if not overridden: perform actual operation on object • Useful for “watching” objects during tests & verifying intended behaviors occurred (verification-based testing)
41. Integration testing
42. Integration testing • Treat application as a black box
43. Integration testing • Treat application as a black box • Downstream services (db, message brokers, etc) need to be available
44. Integration testing • Treat application as a black box • Downstream services (db, message brokers, etc) need to be available • Application should be run & tested as its intended to be deployed
45. Integration testing • Treat application as a black box • Downstream services (db, message brokers, etc) need to be available • Application should be run & tested as its intended to be deployed • Should be run before code is merged
46. Today’s challenge
47. 229449 HTTP (REST) adoptions topic adoption-requests topic Get / Persist pet info
48. https://bit.ly/tdd-easy
50. Additional resources
51. Kubernetes Native Java with Quarkus https://www.infoq.com/articles/native-java-quarkus Deployment Developer Joy • Quickly & easily build Kubernetes-Native Java applications • Industry leader in startup time and memory utilization for native and JVM applications • One step native executable generation • Leverage existing Java, Jakarta, MicroProfile, & Spring expertise • Imperative & reactive APIs side-by-side • Live coding with zero config
52. https://www.oreilly.com/library/view/reactive-systems-in/9781492091714 https://developers.redhat.com/e-books/understanding-quarkus https://developers.redhat.com/e-books/practising-quarkus
53. https://quarkus.io/blog/quarkus-superheroes-to-the-rescue https://github.com/quarkusio/quarkus-super-heroes Quarkus Superheroes
54. https://quarkus.io @quarkusio https://quarkus.io/community
55. Thank you!