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

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é?

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

Effective unit testing

Effective unit testing

Effective unit testing

Test-Driven Design - ¿Porqué?

Test-Driven Design - ¿Porqué?

Test-Driven Design - ¿Porqué?

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

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

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

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

Recently uploaded

Ever caught yourself nodding along when someone mentions "delivering value" in Agile, but secretly wondering what the heck they actually mean? You're not alone! Join us for an eye-opening session where we'll strip away the buzzwords and dive into the heart of Agile—value delivery. But what is "value"? Is it a mythical unicorn in the world of software development, or is there more to this overused term? This isn't going to be a sit-and-get lecture. We're talking about a face-to-face, interactive meetup where YOU play a crucial role. Come along to: Define It: What does "value" really mean? We’ll build a definition that’s not just words, but a compass for your Agile journey. Contextualise It: Discover what value means specifically to you, your team, your company, and your industry. Because one size does not fit all. Deliver It: Share strategies and gather new ones for uncovering and delivering true value—no more shooting in the dark!

Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx

Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx

Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx

The standard Salesforce Approval process can be limiting in many ways, especially in complex scenarios. What if there was a way to implement very flexible approvals where one can use Apex code to make data updates in unrelated records, dynamically generate next steps details, and compute assignees on the fly? And still use UI-based configurations to implement concrete approval processes. In this session, we will share ideas behind such a solution and show a few lines of code to get you started.

Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder

Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder

Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder

In this session, we will showcase how to revolutionize automated testing for your software, automation, and QA teams with UiPath Test Suite. In part 1 of UiPath test automation using UiPath Test Suite – developer series, we will cover, Software testing overview What is software testing Why software testing is required Typical test types and levels Continuous testing and challenges Introduction to UiPath Test Suite UiPath Test Suite family of products Speaker: Atul Trikha, Chief Technologist & Solutions Architect, Peraton and UiPath MVP Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP

UiPath Test Automation using UiPath Test Suite series, part 1

UiPath Test Automation using UiPath Test Suite series, part 1

UiPath Test Automation using UiPath Test Suite series, part 1

ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...

ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...

ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...

Unlock the mysteries of successful Salesforce interviews in this insightful session hosted by Hugo Rosario (Salesforce Customer), a seasoned hiring manager that leads the Salesforce Department of multinational company with over 100 interviews under their belt. Step into the manager's chair and gain exclusive behind-the-scenes insights into what makes a Salesforce consultant stand out during the interview process. From deciphering the unspoken cues to mastering key strategies, we'll explore the intricacies of the interview process and provide practical tips for consultants looking to not only pass interviews but also thrive in their roles. Whether you're a seasoned professional or just starting your Salesforce journey, this session is your backstage pass to the secrets that hiring managers wish you knew.

Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...

Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...

Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...

WSO2CONMay2024OpenSourceConferenceDebrief.pptx

WSO2CONMay2024OpenSourceConferenceDebrief.pptx

WSO2CONMay2024OpenSourceConferenceDebrief.pptx

Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...

Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...

Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Screen flow is a powerful automation tool that is commonly designed for internal and external users. However, what about the guest users? We will dive into various methods of launching screen flows and understand how to make them publicly accessible, extending their usability to a broader audience. The presentation will also cover the implementation of security layers and highlight best practices for a smooth and protected user experience. Discover the potential of screen flows beyond conventional use and learn how to leverage them effectively.

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade

Designing inclusive products is not only a social responsibility but also a business imperative. This talk delves into the journey of creating accessible hardware products that cater to diverse user needs. Key Topics Covered: 1. Introduction to Inclusive Design - Importance of accessibility in product design - Overview of Comcast's commitment to making products accessible to a wide audience 2. Case Study: Xfinity Large Button Voice Remote - Initial challenges and the evolution of the product - User research and feedback that shaped the design - Key features of the final product and their benefits 3. Designing for Diverse Needs - Understanding human-centered design and its historical context - The impact of designing for people with disabilities on overall product quality - Examples from other industries, such as architecture and industrial design 4. Integrating Accessibility from the Beginning - The cost and efficiency benefits of designing for accessibility from the start - The process of embedding accessibility as a core trait rather than an optional feature 5. Real-World Impact and Continuous Improvement - Insights from in-home studies with users having assistive needs - How continuous feedback and iterative design lead to better products - The role of inclusive research and development practices

Designing for Hardware Accessibility at Comcast

Designing for Hardware Accessibility at Comcast

Designing for Hardware Accessibility at Comcast

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf

This presentation dives into the practical applications of machine learning within Google's operations, providing a comprehensive overview of how to leverage AI technologies to solve real-world business challenges. Key Points Covered: - Introduction to Machine Learning at Google: Discussion on the role of ML and its evolution in enhancing Google's operational efficiency. - Experience Sharing: Insights into the team's long-term engagement with machine learning projects and the impacts on Google’s operational strategies. - Practical Applications: Real-world examples of ML applications within Google’s daily operations, providing a blueprint to adapt similar strategies. - Challenges and Solutions: Discussion on the challenges faced during the implementation of ML projects and the strategic solutions employed to overcome them. - Future of ML at Google: Insights into future trends in machine learning at Google and how they plan to continue integrating AI into their ecosystem.

Strategic AI Integration in Engineering Teams

Strategic AI Integration in Engineering Teams

Strategic AI Integration in Engineering Teams

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

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

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

We're living the AI revolution and Salesforce is adapting and bring new value to their customers. Einstein products are evolving rapidly and navigating their limitations, language support, and use cases can be challenging. Let's make review of what Einstein product are available currently, what are the capabilities and what can be used for in CEE region and how Rossie.ai can help to learn Salesforce speak Czech. We will explore the Einstein roadmap and I will make a short live demo (based on your vote) of some Einstein feature.

AI revolution and Salesforce, Jiří Karpíšek

AI revolution and Salesforce, Jiří Karpíšek

AI revolution and Salesforce, Jiří Karpíšek

Discover the top Symfony development companies that excel in creating robust and scalable web applications. Our latest blog highlights the best firms specializing in Symfony, known for their expertise in delivering high-performance solutions. Whether you’re looking to start a new project or enhance an existing one, these companies offer the skills and experience needed to bring your vision to life. Read more to find your perfect Symfony development partner.

Top 10 Symfony Development Companies 2024

Top 10 Symfony Development Companies 2024

Top 10 Symfony Development Companies 2024

IoT Analytics Company Presentation May 2024

IoT Analytics Company Presentation May 2024

IoT Analytics Company Presentation May 2024

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

PLAI - Acceleration Program for Generative A.I. Startups

PLAI - Acceleration Program for Generative A.I. Startups

PLAI - Acceleration Program for Generative A.I. Startups

How to differentiate Sales Cloud and CPQ on first glance might be tricky if you do not know where to look and what to look at. You will know :-) Managing the sales process within Salesforce is a common use case that can be managed with standart Sales Cloud. If you want to do entire quoting process you will find out Salesforce CPQ solution exists. What is then the difference if both can handle selling products? You will see comparison of 10 different features, which Sales Cloud and Salesforce CPQ handle differently. Simple question you will always remember if you should consider using Salesforce CPQ will be a cherry on top.

10 Differences between Sales Cloud and CPQ, Blanka Doktorová

10 Differences between Sales Cloud and CPQ, Blanka Doktorová

10 Differences between Sales Cloud and CPQ, Blanka Doktorová

FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...

FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...

FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...

Recently uploaded (20)

Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx

Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx

Unpacking Value Delivery - Agile Oxford Meetup - May 2024.pptx

Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder

Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder

Custom Approval Process: A New Perspective, Pavel Hrbacek & Anindya Halder

UiPath Test Automation using UiPath Test Suite series, part 1

UiPath Test Automation using UiPath Test Suite series, part 1

UiPath Test Automation using UiPath Test Suite series, part 1

ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...

ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...

ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...

Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...

Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...

Behind the Scenes From the Manager's Chair: Decoding the Secrets of Successfu...

WSO2CONMay2024OpenSourceConferenceDebrief.pptx

WSO2CONMay2024OpenSourceConferenceDebrief.pptx

WSO2CONMay2024OpenSourceConferenceDebrief.pptx

Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...

Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...

Secure Zero Touch enabled Edge compute with Dell NativeEdge via FDO _ Brad at...

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Speed Wins: From Kafka to APIs in Minutes

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade

Free and Effective: Making Flows Publicly Accessible, Yumi Ibrahimzade

Designing for Hardware Accessibility at Comcast

Designing for Hardware Accessibility at Comcast

Designing for Hardware Accessibility at Comcast

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf

Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf

Strategic AI Integration in Engineering Teams

Strategic AI Integration in Engineering Teams

Strategic AI Integration in Engineering Teams

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

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

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

AI revolution and Salesforce, Jiří Karpíšek

AI revolution and Salesforce, Jiří Karpíšek

AI revolution and Salesforce, Jiří Karpíšek

Top 10 Symfony Development Companies 2024

Top 10 Symfony Development Companies 2024

Top 10 Symfony Development Companies 2024

IoT Analytics Company Presentation May 2024

IoT Analytics Company Presentation May 2024

IoT Analytics Company Presentation May 2024

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

PLAI - Acceleration Program for Generative A.I. Startups

PLAI - Acceleration Program for Generative A.I. Startups

PLAI - Acceleration Program for Generative A.I. Startups

10 Differences between Sales Cloud and CPQ, Blanka Doktorová

10 Differences between Sales Cloud and CPQ, Blanka Doktorová

10 Differences between Sales Cloud and CPQ, Blanka Doktorová

FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...

FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...

FDO for Camera, Sensor and Networking Device – Commercial Solutions from VinC...

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