.NET Day 2025: .NET Core Testing: pushing the limits

Transcript

1. .Net core testing: pushing the limits Guillaume SAINT ETIENNE
2. Intro
5. Keep faith in tests
7. What is a Unit Test ?
8. What is a Unit Test ? Fowler: it's a situational thing - the team decides what makes sense to be a unit for the purposes of their understanding of the system and its testing.
9. Unit tests keep things simple https://martinfowler.com/bliki/UnitTest.html
10. Properties of (good) tests • Fast • Isolated • Repeatable • Self-Verifying • Timely https://medium.com/pragmatic-programmers/unit-tests-are-first-fast-isolated-repeatable-self-verifying-and- timely-a83e8070698e
11. Powerful assertions 👑 Wrap in your DtSL 👑 Social Tests Solitary Tests Master LifeCycle + Inject Dependencies Reuse tests Organize tests hierarchy with Stubs plus W.A.F.
14. Let’s see some code ! https://github.com/guillaumeagile/2025-xunit-to-the-limits /tree/v2
15. then Docker came to us 🙏
18. Test cohesion adapter 1 Unit Tests adapter 2 Port 2 Stubs (Spies, Fakes, Mocks ☠)
19. Test cohesion adapter 1 Unit ? Tests adapter 2 Port 2
20. Maintain isolation 1. Clean Setup: 2. No Shared State: 3. Reset State:
21. Choose wisely Identical Behavior ??? 🤔
22. Thug life
23. in docker Bonus: CI/CD friendly
25. Welcome to the new Pyramid
26. UniTegration Tests
27. UniTegration Tests (using Test Containers)
28. https://martinfowler.com/articles/microservice-testing/#testing-unit-diagram
29. https://martinfowler.com/articles/microservice-testing/#testing-unit-diagram agree 👍
30. https://martinfowler.com/articles/microservice-testing/#testing-unit-diagram agree 👍 disagree 👎 Domain code must be pure, therefore avoid any side effects Thus, UnitTests are Solitary there
31. https://martinfowler.com/articles/microservice-testing/#testing-unit-diagram agree 👍 split domain core and use cases 👍 Domain code must be pure, Services (or Use Cases) need to collaborate (as a glue) Core
33. 🤩 We need UniTegration here 👉
34. Discussion
35. Pitfall of Mocks • It’s easy to make mock instances incorrect – no guarantee it’s consistent with a correct implementation, which can lead to brittle tests. • Hard to refactor • Mocks discourage good interface design by encouraging testing implementation details instead of contracts. • Tests should be “executable documentation.” • Because they can use more-magical features like macros and reflection, they are less portable. https://xebia.com/blog/pitfalls-mocking-tests-how-to-avoid/ https://maherz.medium.com/stop-using-mocking-libraries-the-mistake-every-developer-makes-79a5d5189281
36. Hard to Refactor
37. Hard to Refactor (“42”)
38. Harder to maintain “Successful!” even if not 🤔
39. Mocks = Dependency mismatch • Never Mock what you don’t own • Hand-written stub code • Hard, even impossible to refactor when contract OR behaviour changes ! https://www.jamesshore.com/v2/projects/nullables/testing-without-mocks#tradeoffs https://ryanharter.com/blog/2020/06/replacing-mocks/
40. About
41. Test dilemna adapter In Mem Unit Tests Fake
42. Test temptation adapter Unit Tests
43. Test cohesion adapter Unit ? Tests
44. Test cohesion 👎 adapter Unit ? Tests
45. About xUnit and Shared Context between tests https://xunit.net/docs/shared-context
46. About Test Containers and Shared Context https://blog.jetbrains.com/dotnet/2023/10/24/how-to-us e-testcontainers-with-dotnet-unit-tests/
47. ❓
48. • 🙏