What is the right "unit" in unit testing and why it is not a class?

•Download as PPTX, PDF•

0 likes•160 views

Whether you're just writing your first unit test or have been practicing Test Driven Development for many years, I'm sure your biggest challenge is to find the right scope for testing. Unfortunately a lot of books and guidance seem to imply that every class or type should be tested separately. Well, I can tell you from 15 years of unit testing experience that that's the best way to shoot yourself in the foot. In this session, I'm going to show you some concrete examples and why I chose a certain boundary for the "unit" in unit testing. I will also share design heuristics I use myself to find those boundaries and why those are not guidelines. I'll also illustrate how principals like DRY and SOLID can be both a blessing and a curse that may lead to the wrong design choices.

…and why is it not a class
What’s the “unit” in unit testing
Dennis Doomen

About Me
Hands-on architect in the .NET space with 25 years of experience on
an everlasting quest for knowledge to build the right software the right
way at the right time

Why is this important?

Test Driven
Development in
reality
Design class
responsibilities
Write first unit
test
Generate stubs
Fail for the right
reason
Implement
real deal
Ensure test
succeeds
Identify
alternative
scenarios
Repeat twice
Refactor

Heuristics to find the right scope

Designed for
reusability? Then
tested separately

Is it an
implementation
detail? Then don’t
test it directly

Is the test really
testing the real
surface area?

Does refactoring
require rewriting the
tests?

Things in
adjacent folders
usually mean
they are separate

Returning mocks
from mocks is often
a sign of a scope
issue

Real-World Examples

Tips to improve testability

It’s fine to include
the database in tests

It’s fine to test
smaller when it adds
value

Don't bother
arguing about “unit”
vs “integration”

Organize code by
functional
boundaries

Apply DRY within
those boundaries

Mock the
dependencies
outside of the
scope

A less trivial example

Command Handlers
Commands
Domain Model
Event Store
Events
App
Read Data
RavenDB
Projectors
Events
HTTP API
Projections
Events

Test Fixture
In-Memory
Event Store
Read
Data
RavenDB
Projectors
Events
HTTP API
Projections
Unit Test
HTTP request
Test Data

Q&A
…ask at fluentassertions.slack.com
…ping me at @ddoomen
…email me at dennis.doomen@avivasolutions.nl

More Related Content

Similar to What is the right "unit" in unit testing and why it is not a class?

Whether you're just writing your first unit test or have been practicing Test Driven Development for many years, I'm sure your biggest challenge is to find the right scope for testing. Unfortunately a lot of books and guidance seem to imply that every class or type should be tested separately. Well, I can tell you from 15 years of unit testing experience that that's the best way to shoot yourself in the foot. In this session, I'm going to show you some concrete examples and why I chose a certain boundary for the "unit" in unit testing. I will also share design heuristics I use myself to find those boundaries and why those are not guidelines. I'll also illustrate how principals like DRY and SOLID can be both a blessing and a curse that may lead to the wrong design choices

What is the right unit in unit testing (UpdateConf 2022)

What is the right unit in unit testing (UpdateConf 2022)

What is the right unit in unit testing (UpdateConf 2022)

Enough books have been written, articles have been published and Youtube videos have been posted about how you should be behaving as a software developer, Scrum Master or team lead. To be original in this unoriginal world, I started thinking about the things you should NOT be doing. I came up with 50 tools, practices and principles covering topics like dealing with complexity, productivity, architecture, testability, traceability, maintainability, transparency and predictability that I believe hamper you as a professional. That sounds like a lot, but I promise you a fun and entertaining session that I'm sure will trigger a lot of recognition.

50 things software teams should not do.pptx

50 things software teams should not do.pptx

50 things software teams should not do.pptx

Up to speed in domain driven design

Up to speed in domain driven design

Up to speed in domain driven design

Rick van der Arend

The original promise of TDD was that it would assist in guiding the development of clean code, but it often ends up polluting our architecture with excessive composition, is expensive to write, and becomes an obstacle to change, not an aid to refactoring. In this talk, we look at the fallacies of TDD and learn about the key principles that we should be following for mastery of this practice. This talk is intended for those who have been practicing TDD, or who have tried TDD and given up because of shortcomings in the approach they were taught.

Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after

Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after

Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after

Iranian Domain-Driven Design Community

Test Driven Development - Overview and Adoption

Test Driven Development - Overview and Adoption

Test Driven Development - Overview and Adoption

Pyxis Technologies

Software as a Service

Software as a Service

Software as a Service

Michael Falanga

Test-Driven Development

Test-Driven Development

Test-Driven Development

“Do you know a good book about testing software, Wolf?” “Err… actually I don’t. But I know a few things about testing I am happy to share…” This is how it all started. In this session, Wolf is sharing battle hands-on and battle proven approaches to ensuring that quality is baked into our software from day one. Learn about the limitations of test driven design, how to test asynchronous behaviour and the merits of bug bashing (just to name a few). Bio: Wolf is a professionally qualified software engineer with over 20 years of international consulting experience. He works for ThoughtWorks Germany and helps teams delivering working software. Wolf's primary professional interests are microservices, cloud, continuous delivery, agile enablement and humanitarian software.

16 things a developer should know about testing

16 things a developer should know about testing

16 things a developer should know about testing

San Francisco Software Craftsmanship Meetup Test Driven Developers Bay Area Meetup TDD Flow: The Mantra in Action” is a talk + hands-on about the mantra of TDD and its core patterns. Here are some questions for this talk: What is TDD? How to write a good test that fails? How to write code enough to make the test pass? How to remove duplication? How to refactor code? How to create clean code? Is TDD about testing or design? How small should a test be? Should I only write unit tests? Should I estimate TDD? How to use TDD with other agile methods like Scrum, Kanban or BDD? And finally, how to flow in TDD?

TDD Flow: The Mantra in Action

TDD Flow: The Mantra in Action

TDD Flow: The Mantra in Action

Dionatan default

Tdd and-design-draft

Tdd and-design-draft

Tdd and-design-draft

Test Driven Development

Test Driven Development

Test Driven Development

Presented at Agile New England, June 2020, as part of their Agile 101 series. Reviews the 12 XP practices introduced by Kent Beck in Extreme Programming Explained published 1999. The XP practices, once extreme, now mainstream, complement any Agile methodology. XP introduced us to user stories, test driven development, pair programming and continuous integration. These practices changed the way software solutions are planned, developed and designed.

Extreme Programming: An Introduction to XP Practices

Extreme Programming: An Introduction to XP Practices

Extreme Programming: An Introduction to XP Practices

Introduction to Extreme Programming

Introduction to Extreme Programming

Introduction to Extreme Programming

JavaScript Unit Testing

JavaScript Unit Testing

JavaScript Unit Testing

L&T Technology Services Limited

Agile principles and practices

Agile principles and practices

Agile principles and practices

Pair Programming Talk

Pair Programming Talk

Pair Programming Talk

The Test Case as Executable Example

The Test Case as Executable Example

The Test Case as Executable Example

Arie van Deursen

Event Sourcing is becoming more mainstream these days, and a lot of conferences have demonstrated the pros and cons of this architecture style from multiple angles. I've done a few of these and publishes a lot of articles on best practices and solutions to common problems. But what nobody did was to show you how to build an event sourced systems in the .NET ecosystem. There are a lot of open-source projects that you can use, so you'll need to find a right mix and your own code to that. So let me show you how I would implement this in .NET with almost 10 years of Event Sourcing experience behind my belt.

Design patterns for Event Sourcing in .NET

Design patterns for Event Sourcing in .NET

Design patterns for Event Sourcing in .NET

About 15 years ago, I got inspired by a series of posts on Test Driven Development written by the Jeremy D. Miller. Now, with many years of great and not-so-great experiences practicing Test Driven Development, I thought it is the time to capture my own “laws”. The term "law" is obviously an exaggeration and "principles or heuristics" cover my intend much better. Either way, I want to talk about the scope of testing, using the observable behavior, naming conventions, state-based vs interaction-based testing, the impact of DRY, patterns to build useful test objects and some of the libraries and tools I use. In short, everything I try to follow every day I write, review or maintain code.

My Laws of Test Driven Development (2023)

My Laws of Test Driven Development (2023)

My Laws of Test Driven Development (2023)

Effective unit testing

Effective unit testing

Effective unit testing

Roberto Casadei

Similar to What is the right "unit" in unit testing and why it is not a class? (20)

What is the right unit in unit testing (UpdateConf 2022)

What is the right unit in unit testing (UpdateConf 2022)

What is the right unit in unit testing (UpdateConf 2022)

50 things software teams should not do.pptx

50 things software teams should not do.pptx

50 things software teams should not do.pptx

Up to speed in domain driven design

Up to speed in domain driven design

Up to speed in domain driven design

Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after

Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after

Ian Cooper webinar for DDD Iran: Kent beck style tdd seven years after

Test Driven Development - Overview and Adoption

Test Driven Development - Overview and Adoption

Test Driven Development - Overview and Adoption

Software as a Service

Software as a Service

Software as a Service

Test-Driven Development

Test-Driven Development

Test-Driven Development

16 things a developer should know about testing

16 things a developer should know about testing

16 things a developer should know about testing

TDD Flow: The Mantra in Action

TDD Flow: The Mantra in Action

TDD Flow: The Mantra in Action

Tdd and-design-draft

Tdd and-design-draft

Tdd and-design-draft

Test Driven Development

Test Driven Development

Test Driven Development

Extreme Programming: An Introduction to XP Practices

Extreme Programming: An Introduction to XP Practices

Extreme Programming: An Introduction to XP Practices

Introduction to Extreme Programming

Introduction to Extreme Programming

Introduction to Extreme Programming

JavaScript Unit Testing

JavaScript Unit Testing

JavaScript Unit Testing

Agile principles and practices

Agile principles and practices

Agile principles and practices

Pair Programming Talk

Pair Programming Talk

Pair Programming Talk

The Test Case as Executable Example

The Test Case as Executable Example

The Test Case as Executable Example

Design patterns for Event Sourcing in .NET

Design patterns for Event Sourcing in .NET

Design patterns for Event Sourcing in .NET

My Laws of Test Driven Development (2023)

My Laws of Test Driven Development (2023)

My Laws of Test Driven Development (2023)

Effective unit testing

Effective unit testing

Effective unit testing

More from Dennis Doomen

I'm sure every developer wants to be able to change code with confidence and without fear. Readable and self-explanatory code is one aspect of that. Too much coupling is another major source of problems that prevent you from changing one part of the system without causing side-effects. In this talk, I'd like you to show you common sources of unnecessary coupling and offer you options to help prevent and/or break those. I'll talk about how principles like Don't Repeat Yourself and Dependency Injection can be a double-edge sword, how to detect too unnecessary dependencies and how to use the Dependency Inversion Principle to unravel some of those. And yes, I will also talk about controlling dependencies on the package level. Challenge 1. How to prevent too much coupling? 2. We are tought to decrease coupling and increase cohesion 3. How do you increase cohesion? By applying DRY! 4. But DRY creates more coupling 5. And too much decoupling results in a forest of abstractions 6. The solution is… find a balance (or "it depends") On the architecture level 1. Use architecture style that embraces DIP (e.g. Onion, Hexagon, Clean Architecture) 2. Organize your code along functional boundaries -> this will make it easier to break off that boundary for rebuilding/strangler/microservices. 3. Apply DRY within those boundaries only, but allow shared services for complicated capabilities 4. Align your test scope with those internal boundaries… On the package level • Classes and interfaces that are almost always used together should be packaged together. Those that don’t meet that criteria don’t have a place in that package • Packages should not require changes (and thus a new release) for unrelated changes. • There must be no cycles in the dependency structure • A package should only depend upon packages that are more stable than it is or abstract packages On the code level • Avoid technical folders and organize them by functionalities or capabilities • Things in adjacent folders usually mean they are separate boundaries • Use the Tell, Don't Ask principle • Use the Law of Demeter to detect unnecessary coupling • Encapsulate primitive types and collections in specific types • Dependency injection is great, but try to avoid a global container • It's fine to inject concrete classes inside boundaries Strategy for legacy code 1. Ensure you have a safety net using characterisation tests 2. Find existing seams and decouple them better a. Identify modules or functional slices b. Identify groups of classes that are supposed to be used together and are designed to be reusable c. Identify interfaces or abstractions in DI registration code and see if they are truly designed for reusability d. Assume that code in adjacent folders is supposed to be independent e. Move code from different technical folders that belong together in their own (functionally named) folderPublic 3. Use that to define (and visualize) the target architecture

Getting a grip on your code dependencies (2023-10)

Getting a grip on your code dependencies (2023-10)

Getting a grip on your code dependencies (2023-10)

We all love to build greenfield projects, but the reality is that in most jobs you have to deal with a lot of legacy code. This doesn't mean the code is bad. It just means that choices were made that were the right ones at that time, or that the developers were not entire up-to-date with modern development practices. And that's exactly what this talk is about. I enjoy taking such a codebase and gradually introduce architectural seems, add a proper build pipeline, introduce temporary tests and then gradually refactor the codebase to combine more maintainable, testable and reliable. So in this talk, I'd like to unfold my extensive toolbox of practices, principles, tools and mindset to help you improve your legacy code without jeopardizing your business. Understand production environment See which vinaries are running in production and what config files are used Verify the code and the production release are in sync, e.g. DotPeek Analyze logs to understand what features are used Try to get it to run on a local environment Understand code Generate project diagrams and class hierarchies Find origin calls and destination of a parameter using Rider Use navigation options to find inheritors, usages, etc. Use the namespaces and project names to understand the relation Have Rider's AI Assistant or ChatGPT explain the code Track all documentation in a single place Build C4 diagrams Find dead code Reduce the scope of types and members to internal to find more dead code Detect code inefficiencies and dead code using Rider Remove commented out code Build a safety net If therea are tests, add code coverage reporting using Coverlet and use that to find dark spots (HTTP API) Characteristics tests using FluentAssertions, Bogus, xUnit. Use AI to generate them. It's fine, you'll delete them later on Use test containers for .net t lo include the databse Build a couple of end to end UI tests e.g. using Cypress, Playwright, efc Improve deployability Add scripts or builds steps to run the code locally, Nuke build pipeline to get consistency Adopt a version strategy and name branches accordingly Adopt automatic versioning using GitVersion Adopt logging and exception strategy, e.g. Serilog Pulumi to automate PR deployments Improve code Treat all warnings as errors and fix thhem Editorconfig / eslint so auto-format works Configure a personal Rider/R# clean-up profile to auto-format file, project and solution Roslyn analyzers Microsoft.CodeAnalysis.BannedApiAnalyzers StyleCop.Analyzers CSharpGuidelinesAnalyzer Roslynator.Analyzers Meziantou.Analyzer Enable nullable types per file Move new code to .NET 6+ or cross-compile Switch to newer C# versions, possibly using Polysharp File-scope namespaces Target-typed news switch expression String interpolation instead of string.format Use Directory.Build.Props to reduce duplication Improve naming whenever you can Encapsulate prim itive types and collections in d

Tools and practices to help you deal with legacy code

Tools and practices to help you deal with legacy code

Tools and practices to help you deal with legacy code

Providing a high quality library like that doesn't come for free. We've been trying to write code that is clean enough for our contributors, write tests that are self-explanatory, ensure breaking changes are strictly controlled and try to make it easy to use. In this talk, I'd like to share the tools and techniques we have been using. I'll talk about the release strategy, documentation, versioning, naming conventions, code structure, the build pipeline, automated testing, code coverage, API change detection, multi-targeting and more. In this talk, I'd like to share the tools and techniques we have been using, how they've enriched our day jobs, and how they may do that for you too. I'll talk about the release strategy, documentation, versioning, naming conventions, code structure, the build pipeline, automated testing, code coverage, API change detection, multi-targeting and more.

What you can learn from an open-source project with 250 million downloads

What you can learn from an open-source project with 250 million downloads

What you can learn from an open-source project with 250 million downloads

Who remembers the days were you had to manually setup a physical server somewhere in a 19 inch rack? Nowadays those physical racks have been replaced by virtual machines provided by Google, Microsoft and Amazon. But some people are still provisioning them manually. The more mature organizations will script most of the provisioning using the native CLI or HTTP API provided by the specific cloud platform, but quite often those are maintained separately from the code of the system that is being deployed. Terraform by Hashicorp is another attempt to support infrastructure-as-code by using a declarative syntex to define the desired infrastructure. But then again, Yaml isn't really suited for anything but simple single-file configuration settings. Yaml isn't code and doesn't provide real Intellisense, line-by-line debugging and most importantly, refactoring. But what if you could use C# and .NET to provision your infrastructure and treat that code as first-class citizens of your codebase, including all the capabilities that you would expect? Well, let me show you how Pulumi for .NET will allow you to evolve your infrastructure code with the rest of the code base without turning it in a big spaghetti of Yaml files.

Automate Infrastructure with Pulumi and C#

Automate Infrastructure with Pulumi and C#

Automate Infrastructure with Pulumi and C#

I don't have to tell anybody how awesome Event Sourcing is as an architecture style. But those that have been using it in production must have experienced the pains of keeping the upgrades fast enough, especially if you use a more traditional relational database like SQL Server. I've once heard somebody say: "If it's slow, make it faster", but rebuilding a big projection is simply a very expensive operations and involves a lot of network traffic between the application and the database servers. Over the years since we adopted Event Sourcing, we've been experimenting a lot and have implemented various improvements to make those reprojections faster. And we haven't stopped. We're already working on some new ideas lately. So in this session, I'd like to share those techiques, their pros and cons and how we implemented them on a more detailed level.

Slow Event Sourcing (re)projections - Just make them faster!

Slow Event Sourcing (re)projections - Just make them faster!

Slow Event Sourcing (re)projections - Just make them faster!

Writing maintainable code is not something that is easy to do. Not only is a pretty subjective, a lot of the techniques like Clean Code, SOLID and such can be misinterpreted resulting in unconstructive dogma. I've made it my career's goal to find a good balance between all those different patterns, principles, practices and guidelines. In this talk, I'd like to share my own ideas on what it takes to write maintainable code. I'll talk about architecture, class design, automated testing and any consequences on your development process. If you care about your code, be there with me.

A lab around the principles and practices for writing maintainable code

A lab around the principles and practices for writing maintainable code

A lab around the principles and practices for writing maintainable code

It’s 2021, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven’t really changed. Still, Dennis regularly talks to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session Dennis likes to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks.

How to Practice TDD Without Shooting Yourself in the Foot

How to Practice TDD Without Shooting Yourself in the Foot

How to Practice TDD Without Shooting Yourself in the Foot

If I have to name a single biggest hype in software architecture land then it would be "microservice". They are supposed to be small and focused, can be deployed independently, can work with any technology and will solve all your monolithical problems. But we all know that silver bullets don't exist, plus technology should never be a goal, but merely a means to an end. Nonetheless, following the path towards real microservices is a great strategy for decomposing a monolith without the deployment complexity of the first. So how do you do that? What technologies does the .NET realm offer for us? In this talk, I'll show you some of the pros and cons of micro-services and its ingredients to leverage modern-day .NET and Event Sourcing to move your monolith into a bright new future.

Decomposing the Monolith using modern-day .NET and a touch of microservices

Decomposing the Monolith using modern-day .NET and a touch of microservices

Decomposing the Monolith using modern-day .NET and a touch of microservices

Over the years I've spoken many times about what Event Sourcing is and shared many of the good, the bad and the ugly parts of it in blog posts and various talks. However, I've never talked about how to actually build a system based on this architecture style. I keep getting the same questions over and over again. Like when to apply Event Sourcing and at what architectural level. How to deal with transactional boundaries within and outside the domain. How to build projections that are autonomous, reliable and self-supporting. How to deal with upgrades and blue-green deployments. But also on how to handle bugs, design mistakes and crashing projections. Having made a lot of these mistakes myself over these years, it's time to share my current thoughts and opinions about this. Since the .NET space has a pretty rich set of open-source projections to support this, the examples and code will be .NET. But the concepts are universal, so don't let that scare you off.

Event Sourcing from the Trenches (DDD Europe 2020)

Event Sourcing from the Trenches (DDD Europe 2020)

Event Sourcing from the Trenches (DDD Europe 2020)

After several in-depth talks about Event Sourcing, I realized that there's a large group of developers that may have heard about Domain-Driven Design, Command-Query Responsibility Segregation and Event Sourcing, but have not really connected the dots yet. So in this talk, I'd like to take a practical example of a simple domain and gradually introduce functional requirements to see how the principles behind DDD affect the way your entities are going to protect the business rules. After that, I'll introduce some real-world non-functional requirements and see if and how Event Sourcing and/or CQRS may or may not help to accomplish those.

Practical introduction to DDD, CQRS and Event Sourcing

Practical introduction to DDD, CQRS and Event Sourcing

Practical introduction to DDD, CQRS and Event Sourcing

It’s 2019, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven’t really changed. Still, I regularly talk to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session I like to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks. And even if you believe you are well versed in the testing realm, join me anyway. Maybe we can learn some tips & tricks from the audience as well. Looking forward to it!

How to practice TDD without shooting yourself in the foot

How to practice TDD without shooting yourself in the foot

How to practice TDD without shooting yourself in the foot

A micro-service architecture is a great strategy for decomposing a monolith. In this talk, I’ll show you some of the pros and cons of micro-services and how you can leverage OWIN, .NET, Event Sourcing and the Onion Architecture to gradually move your monolith into a bright new future. If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Micro-services are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, micro-services are technology agnostic, but hey, we’re in the .NET space, aren’t we? And they are not a goal, but a means to an end. In fact, a micro-service architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a micro-service? What technologies does the .NET realm offer for us? And what if you don’t want to deploy them independently? In this talk, I’ll show you some of the pros and cons of micro-services and how you can leverage OWIN, .NET, Event Sourcing and the Onion Architecture to gradually move your monolith into a bright new future.

Decomposing the Monolith (Riga Dev Days 2019)

Decomposing the Monolith (Riga Dev Days 2019)

Decomposing the Monolith (Riga Dev Days 2019)

Writing maintainable code is not something that is easy to do. Not only is a pretty subjective, a lot of the techniques like Clean Code, SOLID and such can be misinterpreted resulting in unconstructive dogma. I've made it my career's goal to find a good balance between all those different patterns, principles, practices and guidelines. In this talk, I like to share you my own ideas on what it takes to write maintainable code. I'll talk about architecture, class design, automated testing and any consequences on your development process. If you care about your code, be there with me.

A lab around the principles and practices for writing maintainable code (2019)

A lab around the principles and practices for writing maintainable code (2019)

A lab around the principles and practices for writing maintainable code (2019)

I recently was asked what I would do differently if I had the experience I have now. This got me thinking about the mistakes I've made, the traps I fell for and the dogmatism I became part of over the last 22 years of professional software developer in the Microsoft realm. In this talk, I'll be going down memory lane with you and share everything I've learned on architecture, tools, technologies, agile software development, maintainable code, automated testing, documentation and anything else that I think you should know. Prepare yourself for an event of stories, both good and bad.

Lessons learned from two decades of professional software development

Lessons learned from two decades of professional software development

Lessons learned from two decades of professional software development

In 2009, I first learned about Event Sourcing and Command Query Responsibility Seggregation (CQRS) at a training Greg Young gave in Utrecht, The Netherlands. I remember being awed by the scalability and architectural simplicity those styles provided. However, I also remembered the technical complexity that comes with it. In 2012, I was in charge of transitioning a CQRS-based system to Event Sourcing. I knew it would be non-trivial, but boy was I in for a surprise. So, over the last four years, I've experienced first-hand how a large group of developers had to deal with the transition. It's a brilliant solution for high-performance or complex business systems, but you need to be aware that this also introduces challenges most people don't tell you about. In this talk, I'd like to share you some of the most powerful benefits of ES, but also show you the flipside of the coin and cover some of the smaller and bigger challenges you'll run into it. Again, I love it and would apply it again without any doubt, but I really want you to understand the trade-offs before you jump on the Event Sourcing train.

The Good, The Bad and The Ugly of Event Sourcing

The Good, The Bad and The Ugly of Event Sourcing

The Good, The Bad and The Ugly of Event Sourcing

Over the years I've spoken many times about what Event Sourcing is and shared many of the good, the bad and the ugly parts of it in blog posts and various talks. However, I've never talked about how to actually build a system based on this architecture style. I keep getting the same questions over and over again. Like when to apply Event Sourcing and at what architectural level. How to deal with transactional boundaries within and outside the domain. How to build projections that are autonomous, reliable and self-supporting. How to deal with upgrades and blue-green deployments. But also on how to handle bugs, design mistakes and crashing projections. Having made a lot of these mistakes myself over these years, it's time to share my current thoughts and opinions about this. Since the .NET space has a pretty rich set of open-source projections to support this, the examples and code will be .NET. But the concepts are universal, so don't let that scare you off.

Event Sourcing from the Trenches (with examples from .NET)

Event Sourcing from the Trenches (with examples from .NET)

Event Sourcing from the Trenches (with examples from .NET)

It's 2018, so practices like Test Driven Development (TDD) have long found their way into organizations. However, the practices and principles to keep those unit tests maintainable haven't really changed. Still, I regularly talk to developers that somehow ended up with an incomprehensible unmaintainable set of unit tests that they once believed in, but are now holding them back. So in this session I like to provide a refresh of those fundamental ideas and talk about why you should practice TDD, revealing intentions, naming conventions, state versus interaction based testing, and how to stay out of the debugger hell with proper mocking and assertion frameworks.

How To Practice TDD Without Shooting Yourself In The Foot

How To Practice TDD Without Shooting Yourself In The Foot

How To Practice TDD Without Shooting Yourself In The Foot

If I have to name a single hype in software architecture land then I would have to mention the micro-service architecture. Microservices are supposed to be small, have a very focused purpose, can be deployed independently, are completely self-supporting and loosely coupled. Ideally, microservices are technology agnostic, but hey, we're in the .NET space, aren't we? And they are not a goal, but a means to an end. In fact, a microservice architecture has many benefits and are a great strategy for decomposing a monolith. So how do you build a microservice? What technologies does the .NET realm offer for us? And what if you don't want to deploy them independently? In this talk, I'll show you some of the pros and cons of microservices and how you can leverage Event Sourcing, OWIN and .NET to move your monolith into a bright new future.

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...

Concepts like the Dependency Inversion Principle, Inversion of Control containers and Dependency Injection libraries are often mixed up, but they are not the same. You shouldn’t use a DI library until you understand the problems your solving, nor is it always the best solution. Since I’ve felt this pain many times myself, I’d like to use this session to create some clarity. First, I’ll demonstrate the reason why people typically use libraries like Unity and Autofac in their code bases. Then I’ll show you that those same people often use the Dependency Inversion Principle in the wrong way (and need to revert to mocking libraries to compensate). Then I’ll show you how to apply the principles properly by carefully designing the seams in your architecture. And finally, I’ll show you how an advanced library can connect the dots in a very elegant way.

Strengths and weaknesses of dependency injection

Strengths and weaknesses of dependency injection

Strengths and weaknesses of dependency injection

Frameworks are supposed to help you build things more quicker and hide a lot of complexity around cross-cutting and infrastructural concerns. They are supposed to make it easier for inexperienced developers to join a running projection. But frameworks also introduce a lot of magic, and that magic is going to backfire at some point. At least, that's my experience. And when it backfires, your code is so entangled with that framework, that you can't get rid of it anymore. So, instead of building and using frameworks, build and use libraries. That's easier said then done, and I'll can talk about many great and not so great examples. So let me share some of the practices I use to build composable libraries myself. I'll talk about principles of package design and scoping, keeping your NuGet package dependencies in check, and how to use layered APIs to increase usability without hiding the magic.

Build Libraries That People Love To use

Build Libraries That People Love To use

Build Libraries That People Love To use

More from Dennis Doomen (20)

Getting a grip on your code dependencies (2023-10)

Getting a grip on your code dependencies (2023-10)

Getting a grip on your code dependencies (2023-10)

Tools and practices to help you deal with legacy code

Tools and practices to help you deal with legacy code

Tools and practices to help you deal with legacy code

What you can learn from an open-source project with 250 million downloads

What you can learn from an open-source project with 250 million downloads

What you can learn from an open-source project with 250 million downloads

Automate Infrastructure with Pulumi and C#

Automate Infrastructure with Pulumi and C#

Automate Infrastructure with Pulumi and C#

Slow Event Sourcing (re)projections - Just make them faster!

Slow Event Sourcing (re)projections - Just make them faster!

Slow Event Sourcing (re)projections - Just make them faster!

A lab around the principles and practices for writing maintainable code

A lab around the principles and practices for writing maintainable code

A lab around the principles and practices for writing maintainable code

How to Practice TDD Without Shooting Yourself in the Foot

How to Practice TDD Without Shooting Yourself in the Foot

How to Practice TDD Without Shooting Yourself in the Foot

Decomposing the Monolith using modern-day .NET and a touch of microservices

Decomposing the Monolith using modern-day .NET and a touch of microservices

Decomposing the Monolith using modern-day .NET and a touch of microservices

Event Sourcing from the Trenches (DDD Europe 2020)

Event Sourcing from the Trenches (DDD Europe 2020)

Event Sourcing from the Trenches (DDD Europe 2020)

Practical introduction to DDD, CQRS and Event Sourcing

Practical introduction to DDD, CQRS and Event Sourcing

Practical introduction to DDD, CQRS and Event Sourcing

How to practice TDD without shooting yourself in the foot

How to practice TDD without shooting yourself in the foot

How to practice TDD without shooting yourself in the foot

Decomposing the Monolith (Riga Dev Days 2019)

Decomposing the Monolith (Riga Dev Days 2019)

Decomposing the Monolith (Riga Dev Days 2019)

A lab around the principles and practices for writing maintainable code (2019)

A lab around the principles and practices for writing maintainable code (2019)

A lab around the principles and practices for writing maintainable code (2019)

Lessons learned from two decades of professional software development

Lessons learned from two decades of professional software development

Lessons learned from two decades of professional software development

The Good, The Bad and The Ugly of Event Sourcing

The Good, The Bad and The Ugly of Event Sourcing

The Good, The Bad and The Ugly of Event Sourcing

Event Sourcing from the Trenches (with examples from .NET)

Event Sourcing from the Trenches (with examples from .NET)

Event Sourcing from the Trenches (with examples from .NET)

How To Practice TDD Without Shooting Yourself In The Foot

How To Practice TDD Without Shooting Yourself In The Foot

How To Practice TDD Without Shooting Yourself In The Foot

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...

Decomposing the monolith into embeddable microservices using OWIN, WebHooks, ...

Strengths and weaknesses of dependency injection

Strengths and weaknesses of dependency injection

Strengths and weaknesses of dependency injection

Build Libraries That People Love To use

Build Libraries That People Love To use

Build Libraries That People Love To use

Recently uploaded

As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other? Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.

Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024

Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024

Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024

Discover the essentials of performance testing in the IT sector with our concise guide. Learn about various testing types such as load, stress, endurance, spike, scalability, and volume testing. Understand key performance metrics like response time, throughput, CPU and memory utilization, and error rate. Explore top tools like Apache JMeter, LoadRunner, Gatling, Neoload, and BlazeMeter. Gain insights into best practices for defining objectives, creating realistic scenarios, automating tests, and optimizing performance to ensure user satisfaction, reliability, scalability, and cost efficiency. Ideal for developers, QA engineers, and IT professionals. Visit Expeed Software for more information. https://expeed.com/

In-Depth Performance Testing Guide for IT Professionals

In-Depth Performance Testing Guide for IT Professionals

In-Depth Performance Testing Guide for IT Professionals

Expeed Software

In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development. This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.

PHP Frameworks: I want to break free (IPC Berlin 2024)

PHP Frameworks: I want to break free (IPC Berlin 2024)

PHP Frameworks: I want to break free (IPC Berlin 2024)

In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring. Learn about: • The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks. • Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective. • Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification. • Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process. Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.

Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality

Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality

Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality

Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place. Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects. Here’s what you’ll gain: - Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows. - Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy. - Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency. - Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity. We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic. Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.

Essentials of Automations: Optimizing FME Workflows with Parameters

Essentials of Automations: Optimizing FME Workflows with Parameters

Essentials of Automations: Optimizing FME Workflows with Parameters

Designing Great Products: The Power of Design and Leadership by Chief Designe...

Designing Great Products: The Power of Design and Leadership by Chief Designe...

Designing Great Products: The Power of Design and Leadership by Chief Designe...

The Future of Platform Engineering

The Future of Platform Engineering

The Future of Platform Engineering

Jemma Hussein Allen

💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™: See how to accelerate model training and optimize model performance with active learning Learn about the latest enhancements to out-of-the-box document processing – with little to no training required Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath. Speakers: 👨‍🏫 Andras Palfi, Senior Product Manager, UiPath 👩‍🏫 Lenka Dulovicova, Product Program Manager, UiPath

Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...

Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...

Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...

UiPathCommunity

The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more. Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/ Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.

Transcript: Selling digital books in 2024: Insights from industry leaders - T...

Transcript: Selling digital books in 2024: Insights from industry leaders - T...

Transcript: Selling digital books in 2024: Insights from industry leaders - T...

FIDO Alliance Osaka Seminar: FIDO Security Aspects.pdf

FIDO Alliance Osaka Seminar: FIDO Security Aspects.pdf

FIDO Alliance Osaka Seminar: FIDO Security Aspects.pdf

Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application. In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics. Length: 30 minutes Session Overview ------------------------------------------- During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana: - What out-of-the-box solutions are available for real-time monitoring JMeter tests? - What are the benefits of integrating InfluxDB and Grafana into the load testing stack? - Which features are provided by Grafana? - Demonstration of InfluxDB and Grafana using a practice web application To view the webinar recording, go to: https://www.rttsweb.com/jmeter-integration-webinar

JMeter webinar - integration with InfluxDB and Grafana

JMeter webinar - integration with InfluxDB and Grafana

JMeter webinar - integration with InfluxDB and Grafana

Key Trends Shaping the Future of Infrastructure.pdf

Key Trends Shaping the Future of Infrastructure.pdf

Key Trends Shaping the Future of Infrastructure.pdf

Welcome to UiPath Test Automation using UiPath Test Suite series part 2. In this session, we will cover API test automation along with a web automation demo. Topics covered: Test Automation introduction API Example of API automation Web automation demonstration Speaker Pathrudu Chintakayala, Associate Technical Architect @Yash and UiPath MVP Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP

UiPath Test Automation using UiPath Test Suite series, part 2

UiPath Test Automation using UiPath Test Suite series, part 2

UiPath Test Automation using UiPath Test Suite series, part 2

From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...

From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...

From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...

FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf

FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf

FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf

Quantum Computing: Current Landscape and the Future Role of APIs

Quantum Computing: Current Landscape and the Future Role of APIs

Quantum Computing: Current Landscape and the Future Role of APIs

FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf

FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf

FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf

IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx

IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx

IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx

From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...

From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...

From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Recently uploaded (20)

Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024

Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024

Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024

In-Depth Performance Testing Guide for IT Professionals

In-Depth Performance Testing Guide for IT Professionals

In-Depth Performance Testing Guide for IT Professionals

PHP Frameworks: I want to break free (IPC Berlin 2024)

PHP Frameworks: I want to break free (IPC Berlin 2024)

PHP Frameworks: I want to break free (IPC Berlin 2024)

Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality

Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality

Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered Quality

Essentials of Automations: Optimizing FME Workflows with Parameters

Essentials of Automations: Optimizing FME Workflows with Parameters

Essentials of Automations: Optimizing FME Workflows with Parameters

Designing Great Products: The Power of Design and Leadership by Chief Designe...

Designing Great Products: The Power of Design and Leadership by Chief Designe...

Designing Great Products: The Power of Design and Leadership by Chief Designe...

The Future of Platform Engineering

The Future of Platform Engineering

The Future of Platform Engineering

Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...

Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...

Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...

Transcript: Selling digital books in 2024: Insights from industry leaders - T...

Transcript: Selling digital books in 2024: Insights from industry leaders - T...

Transcript: Selling digital books in 2024: Insights from industry leaders - T...

FIDO Alliance Osaka Seminar: FIDO Security Aspects.pdf

FIDO Alliance Osaka Seminar: FIDO Security Aspects.pdf

FIDO Alliance Osaka Seminar: FIDO Security Aspects.pdf

JMeter webinar - integration with InfluxDB and Grafana

JMeter webinar - integration with InfluxDB and Grafana

JMeter webinar - integration with InfluxDB and Grafana

Key Trends Shaping the Future of Infrastructure.pdf

Key Trends Shaping the Future of Infrastructure.pdf

Key Trends Shaping the Future of Infrastructure.pdf

UiPath Test Automation using UiPath Test Suite series, part 2

UiPath Test Automation using UiPath Test Suite series, part 2

UiPath Test Automation using UiPath Test Suite series, part 2

From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...

From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...

From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...

FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf

FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf

FIDO Alliance Osaka Seminar: Passkeys and the Road Ahead.pdf

Quantum Computing: Current Landscape and the Future Role of APIs

Quantum Computing: Current Landscape and the Future Role of APIs

Quantum Computing: Current Landscape and the Future Role of APIs

FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf

FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf

FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf

IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx

IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx

IOS-PENTESTING-BEGINNERS-PRACTICAL-GUIDE-.pptx

From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...

From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...

From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

What is the right "unit" in unit testing and why it is not a class?

1. …and why is it not a class What’s the “unit” in unit testing Dennis Doomen

2. About Me Hands-on architect in the .NET space with 25 years of experience on an everlasting quest for knowledge to build the right software the right way at the right time

3.

4. Why is this important?

5. Test Driven Development in reality Design class responsibilities Write first unit test Generate stubs Fail for the right reason Implement real deal Ensure test succeeds Identify alternative scenarios Repeat twice Refactor

6. Heuristics to find the right scope

7. Designed for reusability? Then tested separately

8. Is it an implementation detail? Then don’t test it directly

9. Is the test really testing the real surface area?

10. Does refactoring require rewriting the tests?

11. Things in adjacent folders usually mean they are separate

12. Returning mocks from mocks is often a sign of a scope issue

13. Real-World Examples

14.

15.

16.

17.

18. Tips to improve testability

19. It’s fine to include the database in tests

20. It’s fine to test smaller when it adds value

21. Don't bother arguing about “unit” vs “integration”

22. Organize code by functional boundaries

23. Apply DRY within those boundaries

24. Mock the dependencies outside of the scope

25. A less trivial example

26. Command Handlers Commands Domain Model Event Store Events App Read Data RavenDB Projectors Events HTTP API Projections Events

27. Test Fixture In-Memory Event Store Read Data RavenDB Projectors Events HTTP API Projections Unit Test HTTP request Test Data

28. Q&A …ask at fluentassertions.slack.com …ping me at @ddoomen …email me at dennis.doomen@avivasolutions.nl