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

•Als PPTX, PDF herunterladen•

0 gefällt mir•158 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

Weitere ähnliche Inhalte

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

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

Effective unit testing

Effective unit testing

Effective unit testing

Roberto Casadei

Test-Driven Design (TDD) es una idea aparentemente simple: Escriba las pruebas para su código antes de escribir el código. Es "aparentemente simple" por que transforma el rol que testing juega en el proceso de desarrollo y cuestiona nuestros supuestos en la industria sobre el objetivo de testing. Testing ya no es solo acerca de evitar que los defectos lleguen al usuarios finales. Testing consiste en ayudar al equipo a entender las funcionalidad que los usuarios necesitan y hacer entrega de esas funcionalidad de forma confiable y productiva. Cuando TDD se sigue hasta sus últimas consecuencias, ocurren cambios radicales en la forma que desarrollamos software, la calidad de los sistemas que construimos mejora dramáticamente en términos de fiabilidad y flexibilidad en respuesta a nuevos requerimientos. En esta charla: • Los Administradores y Directores recibirán una justificación estratégica a nivel de negocios sobre TDD.

Test-Driven Design - ¿Porqué?

Test-Driven Design - ¿Porqué?

Test-Driven Design - ¿Porqué?

No more Three Tier - A path to a better code for Cloud and Azure

No more Three Tier - A path to a better code for Cloud and Azure

No more Three Tier - A path to a better code for Cloud and Azure

Test Driven Development

Test Driven Development

Test Driven Development

Software Design for Testability

Software Design for Testability

Software Design for Testability

The importance to be Driven There are many buzzwords and acronyms to describe how the software should be designed. TDD (Test Driven), BDD (Behaviour Driven), DDD (Domain Driven) are the most well known. In this speech we'll run thought all these techniques comparing each one of those with TDD and finding what are the common concepts. An exercise will show to the students how different the code will be using different design methodologies as driver.

Importance Of Being Driven

Importance Of Being Driven

Importance Of Being Driven

Antonio Terreno

Human computer interaction research at ibm t

Human computer interaction research at ibm t

Human computer interaction research at ibm t

Ähnlich wie What is the right "unit" in unit testing and why it is not a class? (20)

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

Effective unit testing

Effective unit testing

Effective unit testing

Test-Driven Design - ¿Porqué?

Test-Driven Design - ¿Porqué?

Test-Driven Design - ¿Porqué?

No more Three Tier - A path to a better code for Cloud and Azure

No more Three Tier - A path to a better code for Cloud and Azure

No more Three Tier - A path to a better code for Cloud and Azure

Test Driven Development

Test Driven Development

Test Driven Development

Software Design for Testability

Software Design for Testability

Software Design for Testability

Importance Of Being Driven

Importance Of Being Driven

Importance Of Being Driven

Human computer interaction research at ibm t

Human computer interaction research at ibm t

Human computer interaction research at ibm t

Mehr von 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

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.

Getting a grip on your code dependencies

Getting a grip on your code dependencies

Getting a grip on your code dependencies

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

Mehr von 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

Getting a grip on your code dependencies

Getting a grip on your code dependencies

Getting a grip on your code dependencies

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

Kürzlich hochgeladen

AXA XL - Insurer Innovation Award Americas 2024

AXA XL - Insurer Innovation Award Americas 2024

AXA XL - Insurer Innovation Award Americas 2024

The Digital Insurer

💥 You’re lucky! We’ve found two different (lead) developers that are willing to share their valuable lessons learned about using UiPath Document Understanding! Based on recent implementations in appealing use cases at Partou and SPIE. Don’t expect fancy videos or slide decks, but real and practical experiences that will help you with your own implementations. 📕 Topics that will be addressed: • Training the ML-model by humans: do or don't? • Rule-based versus AI extractors • Tips for finding use cases • How to start 👨‍🏫👨‍💻 Speakers: o Dion Morskieft, RPA Product Owner @Partou o Jack Klein-Schiphorst, Automation Developer @Tacstone Technology

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

UiPathCommunity

Corporate and higher education. Two industries that, in the past, have had a clear divide with very little crossover. The difference in goals, learning styles and objectives paved the way for differing learning technologies platforms to evolve. Now, those stark lines are blurring as both sides are discovering they have content that’s relevant to the other. Join Tammy Rutherford as she walks through the pros and cons of corporate and higher ed collaborating. And the challenges of these different technology platforms working together for a brighter future.

Corporate and higher education May webinar.pptx

Corporate and higher education May webinar.pptx

Corporate and higher education May webinar.pptx

Rustici Software

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Juan lago vázquez

Tracing the root cause of a performance issue requires a lot of patience, experience, and focus. It’s so hard that we sometimes attempt to guess by trying out tentative fixes, but that usually results in frustration, messy code, and a considerable waste of time and money. This talk explains how to correctly zoom in on a performance bottleneck using three levels of profiling: distributed tracing, metrics, and method profiling. After we learn to read the JVM profiler output as a flame graph, we explore a series of bottlenecks typical for backend systems, like connection/thread pool starvation, invisible aspects, blocking code, hot CPU methods, lock contention, and Virtual Thread pinning, and we learn to trace them even if they occur in library code you are not familiar with. Attend this talk and prepare for the performance issues that will eventually hit any successful system. About authorWith two decades of experience, Victor is a Java Champion working as a trainer for top companies in Europe. Five thousands developers in 120 companies attended his workshops, so he gets to debate every week the challenges that various projects struggle with. In return, Victor summarizes key points from these workshops in conference talks and online meetups for the European Software Crafters, the world’s largest developer community around architecture, refactoring, and testing. Discover how Victor can help you on victorrentea.ro : company training catalog, consultancy and YouTube playlists.

Finding Java's Hidden Performance Traps @ DevoxxUK 2024

Finding Java's Hidden Performance Traps @ DevoxxUK 2024

Finding Java's Hidden Performance Traps @ DevoxxUK 2024

Axa Assurance Maroc - Insurer Innovation Award 2024

Axa Assurance Maroc - Insurer Innovation Award 2024

Axa Assurance Maroc - Insurer Innovation Award 2024

The Digital Insurer

Passkeys: Developing APIs to enable passwordless authentication Cody Salas, Sr Developer Advocate | Solutions Architect - Yubico Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

Effective data discovery is crucial for maintaining compliance and mitigating risks in today's rapidly evolving privacy landscape. However, traditional manual approaches often struggle to keep pace with the growing volume and complexity of data. Join us for an insightful webinar where industry leaders from TrustArc and Privya will share their expertise on leveraging AI-powered solutions to revolutionize data discovery. You'll learn how to: - Effortlessly maintain a comprehensive, up-to-date data inventory - Harness code scanning insights to gain complete visibility into data flows leveraging the advantages of code scanning over DB scanning - Simplify compliance by leveraging Privya's integration with TrustArc - Implement proven strategies to mitigate third-party risks Our panel of experts will discuss real-world case studies and share practical strategies for overcoming common data discovery challenges. They'll also explore the latest trends and innovations in AI-driven data management, and how these technologies can help organizations stay ahead of the curve in an ever-changing privacy landscape.

TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery

TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery

TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery

2024: Domino Containers - The Next Step. News from the Domino Container commu...

2024: Domino Containers - The Next Step. News from the Domino Container commu...

2024: Domino Containers - The Next Step. News from the Domino Container commu...

Martijn de Jong

AWS Community Day CPH - Three problems of Terraform

AWS Community Day CPH - Three problems of Terraform

AWS Community Day CPH - Three problems of Terraform

Andrey Devyatkin

Webinar Recording: https://www.panagenda.com/webinars/why-teams-call-analytics-is-critical-to-your-entire-business Nothing is as frustrating and noticeable as being in an important call and being unable to see or hear the other person. Not surprising then, that issues with Teams calls are among the most common problems users call their helpdesk for. Having in depth insight into everything relevant going on at the user’s device, local network, ISP and Microsoft itself during the call is crucial for good Microsoft Teams Call quality support. To ensure a quick and adequate solution and to ensure your users get the most out of their Microsoft 365. But did you know that ‘bad calls’ are also an excellent indicator of other problems arising? Precisely because it is so noticeable!? Like the canary in the mine, bad calls can be early indicators of problems. Problems that might otherwise not have been noticed for a while but can have a big impact on productivity and satisfaction. Join this session by Christoph Adler to learn how true Microsoft Teams call quality analytics helped other organizations troubleshoot bad calls and identify and fix problems that impacted Teams calls or the use of Microsoft365 in general. See what it can do to keep your users happy and productive! In this session we will cover - Why CQD data alone is not enough to troubleshoot call problems - The importance of attributing call problems to the right call participant - What call quality analytics can do to help you quickly find, fix-, and prevent problems - Why having retrospective detailed insights matters - Real life examples of how others have used Microsoft Teams call quality monitoring to problem shoot problems with their ISP, network, device health and more.

Why Teams call analytics are critical to your entire business

Why Teams call analytics are critical to your entire business

Why Teams call analytics are critical to your entire business

CNIC Information System with Pakdata Cf In Pakistan

CNIC Information System with Pakdata Cf In Pakistan

CNIC Information System with Pakdata Cf In Pakistan

Three things you will take away from the session: • How to run an effective tenant-to-tenant migration • Best practices for before, during, and after migration • Tips for using migration as a springboard to prepare for Copilot in Microsoft 365 Main ideas: Migration Overview: The presentation covers the current reality of cross-tenant migrations, the triggers, phases, best practices, and benefits of a successful tenant migration Considerations: When considering a migration, it is important to consider the migration scope, performance, customization, flexibility, user-friendly interface, automation, monitoring, support, training, scalability, data integrity, data security, cost, and licensing structure Next Wave: The next wave of change includes the launch of Copilot, which requires businesses to be prepared for upcoming changes related to Copilot and the cloud, and to consolidate data and tighten governance ShareGate: ShareGate can help with pre-migration analysis, configurable migration tool, and automated, end-user driven collaborative governance

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff

The value of a flexible API Management solution for Open Banking Steve Melan, Manager for IT Innovation and Architecture - State's and Saving's Bank of Luxembourg Apidays New York 2024: The API Economy in the AI Era (April 30 & May 1, 2024) ------ Check out our conferences at https://www.apidays.global/ Do you want to sponsor or talk at one of our conferences? https://apidays.typeform.com/to/ILJeAaV8 Learn more on APIscene, the global media made by the community for the community: https://www.apiscene.io Explore the API ecosystem with the API Landscape: https://apilandscape.apiscene.io/

Apidays New York 2024 - The value of a flexible API Management solution for O...

Apidays New York 2024 - The value of a flexible API Management solution for O...

Apidays New York 2024 - The value of a flexible API Management solution for O...

Exploring Multimodal Embeddings with Milvus

Exploring Multimodal Embeddings with Milvus

Exploring Multimodal Embeddings with Milvus

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

Abhishek Deb(1), Mr Abdul Kalam(2) M. Des (UX) , School of Design, DIT University , Dehradun. This paper explores the future potential of AI-enabled smartphone processors, aiming to investigate the advancements, capabilities, and implications of integrating artificial intelligence (AI) into smartphone technology. The research study goals consist of evaluating the development of AI in mobile phone processors, analyzing the existing state as well as abilities of AI-enabled cpus determining future patterns as well as chances together with reviewing obstacles as well as factors to consider for more growth.

Exploring the Future Potential of AI-Enabled Smartphone Processors

Exploring the Future Potential of AI-Enabled Smartphone Processors

Exploring the Future Potential of AI-Enabled Smartphone Processors

Boost Fertility New Invention Ups Success Rates.pdf

Boost Fertility New Invention Ups Success Rates.pdf

Boost Fertility New Invention Ups Success Rates.pdf

sudhanshuwaghmare1

Following the popularity of “Cloud Revolution: Exploring the New Wave of Serverless Spatial Data,” we’re thrilled to announce this much-anticipated encore webinar. In this sequel, we’ll dive deeper into the Cloud-Native realm by uncovering practical applications and FME support for these new formats, including COGs, COPC, FlatGeoBuf, GeoParquet, STAC, and ZARR. Building on the foundation laid by industry leaders Michelle Roby of Radiant Earth and Chris Holmes of Planet in the first webinar, this second part offers an in-depth look at the real-world application and behind-the-scenes dynamics of these cutting-edge formats. We will spotlight specific use-cases and workflows, showcasing their efficiency and relevance in practical scenarios. Discover the vast possibilities each format holds, highlighted through detailed discussions and demonstrations. Our expert speakers will dissect the key aspects and provide critical takeaways for effective use, ensuring attendees leave with a thorough understanding of how to apply these formats in their own projects. Elevate your understanding of how FME supports these cutting-edge technologies, enhancing your ability to manage, share, and analyze spatial data. Whether you’re building on knowledge from our initial session or are new to the serverless spatial data landscape, this webinar is your gateway to mastering cloud-native formats in your workflows.

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Angeliki Cooney has spent over twenty years at the forefront of the life sciences industry, working out of Wynantskill, NY. She is highly regarded for her dedication to advancing the development and accessibility of innovative treatments for chronic diseases, rare disorders, and cancer. Her professional journey has centered on strategic consulting for biopharmaceutical companies, facilitating digital transformation, enhancing omnichannel engagement, and refining strategic commercial practices. Angeliki's innovative contributions include pioneering several software-as-a-service (SaaS) products for the life sciences sector, earning her three patents. As the Senior Vice President of Life Sciences at Avenga, Angeliki orchestrated the firm's strategic entry into the U.S. market. Avenga, a renowned digital engineering and consulting firm, partners with significant entities in the pharmaceutical and biotechnology fields. Her leadership was instrumental in expanding Avenga's client base and establishing its presence in the competitive U.S. market.

Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...

Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...

Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...

Angeliki Cooney

Kürzlich hochgeladen (20)

AXA XL - Insurer Innovation Award Americas 2024

AXA XL - Insurer Innovation Award Americas 2024

AXA XL - Insurer Innovation Award Americas 2024

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam

Corporate and higher education May webinar.pptx

Corporate and higher education May webinar.pptx

Corporate and higher education May webinar.pptx

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood

Finding Java's Hidden Performance Traps @ DevoxxUK 2024

Finding Java's Hidden Performance Traps @ DevoxxUK 2024

Finding Java's Hidden Performance Traps @ DevoxxUK 2024

Axa Assurance Maroc - Insurer Innovation Award 2024

Axa Assurance Maroc - Insurer Innovation Award 2024

Axa Assurance Maroc - Insurer Innovation Award 2024

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

Apidays New York 2024 - Passkeys: Developing APIs to enable passwordless auth...

TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery

TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery

TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery

2024: Domino Containers - The Next Step. News from the Domino Container commu...

2024: Domino Containers - The Next Step. News from the Domino Container commu...

2024: Domino Containers - The Next Step. News from the Domino Container commu...

AWS Community Day CPH - Three problems of Terraform

AWS Community Day CPH - Three problems of Terraform

AWS Community Day CPH - Three problems of Terraform

Why Teams call analytics are critical to your entire business

Why Teams call analytics are critical to your entire business

Why Teams call analytics are critical to your entire business

CNIC Information System with Pakdata Cf In Pakistan

CNIC Information System with Pakdata Cf In Pakistan

CNIC Information System with Pakdata Cf In Pakistan

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff

Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff

Apidays New York 2024 - The value of a flexible API Management solution for O...

Apidays New York 2024 - The value of a flexible API Management solution for O...

Apidays New York 2024 - The value of a flexible API Management solution for O...

Exploring Multimodal Embeddings with Milvus

Exploring Multimodal Embeddings with Milvus

Exploring Multimodal Embeddings with Milvus

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER

Exploring the Future Potential of AI-Enabled Smartphone Processors

Exploring the Future Potential of AI-Enabled Smartphone Processors

Exploring the Future Potential of AI-Enabled Smartphone Processors

Boost Fertility New Invention Ups Success Rates.pdf

Boost Fertility New Invention Ups Success Rates.pdf

Boost Fertility New Invention Ups Success Rates.pdf

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME

Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...

Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...

Biography Of Angeliki Cooney | Senior Vice President Life Sciences | Albany, ...

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