My Laws of Test Driven Development (2023)

•Transferir como PPTX, PDF•

0 gostou•135 visualizações

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

Tecnologia

Guidelines and heuristics that will help you reach the Plateau of
Productivity
My 25-ish “laws” of Test Driven Development
Dennis Doomen
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

About Me
Hands-on architect in the .NET space with 26 years of experience on
an everlasting quest for knowledge to build the right software the right
way at the right time
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

The Adoption Cycle for Test Driven Development
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Design for Testability
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Design class
responsibilities
Write first test
Generate stubs
Fail for the right
reason
Implement
real deal
Ensure test
succeeds
Identify alternative
scenarios
Repeat twice
Refactor
Start designing
responsibilities before
you write your first test

Then use the tests to drive the design
further
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Organize code by functionalities / capabilities

Use the Dependency
Inversion Principle to
decouple boundaries
Order Processing
IStoreOrders<T>
+ Query<T>();
+ Add<T>();
+ Delete<T>();
NHibernate
Repository
Order Processing
IStoreOrders
+ GetIncompleteOrders(minValue);
+ StoreOrder();
+ CompleteOrder();
OrderRepository
VS
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Apply DRY within those boundaries
Duplicated
Service 1
Duplicated
Service 1
Duplicated
Service 2
Duplicated
Service 2
Duplicated
Service 1
Centralized
Service 3
Extension
Methods
Extension
Methods
Extension
Methods
Extension
Methods
Helpers Helpers Helpers Helpers

Use the right scope
Dennis Doomen | @ddoomen | The Continuous Improver

Service Service
Service Service
Service
Centralized
Service
Align your test scope with those “boundaries”

But sometimes,
testing smaller is
fine too
Application
Functional Slice
Service
Critical Internal
Component
Internal
Component

Test things designed to
reusable separately…

…but test
implementation details
as part of a bigger scope

Treat adjacent folders as
separate boundaries

Don’t bother defining
what “unit” vs
“integration” is

Test guidelines
Dennis Doomen | @ddoomen | The Continuous Improver

Write your tests like you
write your production
code

Allow your tests to be
used as documentation

It’s fine to inject concrete
classes inside boundaries
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Use mocking
between
boundaries but
avoid using them
internally
Service Service
Service Service
Service
Centralized
Service
Can use mocking
Can use
mocking
Can use mocking
Can use
mocking
Avoid
mocking
Avoid
mocking
Avoid
mocking
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Don’t return mocks from mocks
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Hide things that
are not important
for that specific
test

Ensure it fails or
succeeds for the right
reason

Prefer inline literal
strings and numbers
over constants
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Don’t use production code in
assertions
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Only assert what’s
relevant for that specific
test case
@ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

Postfix with Specs to
emphasize tests are
specifications

Group test by API or
purpose using nested
classes

Q&A
(and win a 1-year license for the JetBrains Suite)
…ping me at @ddoomen
…email me at dennis.doomen@avivasolutions.nl

Mais conteúdo relacionado

Mais procurados

Kubernetes ecosystem is seeing adoption across the industry and is on the path to becoming the de-facto orchestration platform on modern cloud service delivery. Kubernetes not only provides primitives for deploying run microservices in the cloud but goes one step further and helps you define interactions and lifecycle for your APIs. The Ingress API in Kubernetes allows you to expose your microservice to the outside world and define routing policies for your north-south traffic (or traffic coming into your virtual data center). We invite Harry Bagdi, Sr. Cloud to discuss in-depth about the design and why of Ingress resource, the benefits of using Ingress to manage your API lifecycle using CI/CD pipelines, and how you can accomplish Ingress using a popular open-source solution, Kong. Kong’s Ingress Controller implements authentication, load-balancing, traffic throttling, transformations, caching, metrics, and logging across Kubernetes clusters.

Kuberntes Ingress with Kong

Nebulaworks

Container World 2018

aspyker

Cloud Native In-Depth

Siva Rama Krishna Chunduru

Redis for duplicate detection on real time stream

Roberto Franchini

Kubernetes PPT.pptx

ssuser0cc9131

Deploying deep learning models with Docker and Kubernetes

PetteriTeikariPhD

Troubleshooting Webex and Microsoft Teams with ThousandEyes

ThousandEyes

Docker: From Zero to Hero

fazalraja

Hashicorp Vault - OPEN Public Sector

Kangaroot

Hadoop Interview Questions and Answers by rohit kapa

kapa rohit

Android gestures v1

Milind Chaskar

SpringBoot and Spring Cloud Service for MSA

Oracle Korea

Data Stores @ Netflix

Vinay Kumar Chella

Introduction to Docker Compose

Ajeet Singh Raina

HDFS User Reference

Biju Nair

Low code with Flowable

Flowable

This presentation, following the previous "An Introduction to the Linux Kernel and Device Drivers", is for another 3-hours lecture in the "Open Source System Software & Practice" class, organized and hosted by Prof. Shih-Hao Hung, in the Department of Computer Science and Information Engineering, National Taiwan University. The slides cover the architecture of the Android Framework, including the Android architecture overview, system integration of the Android operating system, the Activity and Service framework components, life cycles, inter-component communication methods, how the framework works, the Android device control model, core system services, hardware abstraction layer, and related important issues, etc.

An Introduction to the Android Framework -- a core architecture view from app...

William Liang

Spring Boot on Amazon Web Services with Spring Cloud AWS

VMware Tanzu

Clean architecture

.NET Crowd

What is Docker

Pavel Klimiankou

Mais procurados (20)

Kuberntes Ingress with Kong

Container World 2018

Cloud Native In-Depth

Redis for duplicate detection on real time stream

Kubernetes PPT.pptx

Deploying deep learning models with Docker and Kubernetes

Troubleshooting Webex and Microsoft Teams with ThousandEyes

Docker: From Zero to Hero

Hashicorp Vault - OPEN Public Sector

Hadoop Interview Questions and Answers by rohit kapa

Android gestures v1

SpringBoot and Spring Cloud Service for MSA

Data Stores @ Netflix

Introduction to Docker Compose

HDFS User Reference

Low code with Flowable

An Introduction to the Android Framework -- a core architecture view from app...

Spring Boot on Amazon Web Services with Spring Cloud AWS

Clean architecture

What is Docker

Semelhante a My Laws of Test Driven Development (2023)

Behavior Driven Development is one of the most commonly misunderstood techniques in DevOps, but it is also one of the key enablers of both an Agile culture and true continuous deployment. This talk will attempt to fill in the missing pieces on exactly what BDD is and how your teams can use it to increase communication, drive quality, and reduce waste. We will also connect the dots on why you need a test-first strategy to enable trunk-based development, continuous integration, and continuous deployment. If your business still struggles with monthly or quarterly big-batch releases, this talk will show you what your teams must do to evolve to the next stage of continuous delivery.

How BDD enables True CI/CD

Roger Turnau

This is a practitioner’s view of testing and testing practices within an iterative development environment. We will explore the challenges of testing within such an environment and ways to better integrate the QA professional into what is inherently a developer-centric methodology. If quality is paramount, then we ought to move testing to the front of the line and test early and often. Automation lies at the heart of agility and we will look at how test automation techniques and test-first design philosophy might be applied at multiple-levels to drive quality.

Effective Testing Practices in an Agile Environment

Raj Indugula

Journey of atdd

Devesh Maheshwari

Test-Driven Development

adrianmitev

Test Driven Development - Overview and Adoption

Pyxis Technologies

Introduction to Test Driven Development

Michael Denomy

Reduce Development Cost with Test Driven Development

sthicks14

Behavior Driven Development—A Guide to Agile Practices by Josh Eastman

QA or the Highway

Pega robotics best practices building solutions (1)

KPMG US

Pega Robotics Training @Phno: whatsapp @8142976573.

Santhoo Vardan

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

David Alfaro

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

Iranian Domain-Driven Design Community

Getting a grip on your code dependencies

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)

Dennis Doomen

Building rich domain models with ddd and tdd ivan paulovich - betsson

Ivan Paulovich

Project Control is a new mathematical model and method which allows the user to create fully testable solutions to every stage of a development process. Adapted from control theory and inspired by Test Driven Development (TDD); the models allow us to create tests first and ensure we are following a scientific method. Using Control Theory models and Boolean logic for a test and solution; we have created a mathematical method to create fully testable solutions. Use with Obstacle Driven Development to create solutions for every stage of a development which are fully testable.

How to Use Project Control 1.0

Jonathan Herring

TDD and S.O.L.I.D.; Two Ingredients For High Quality Software

Dennis Doomen

Darius Silingas - From Model Driven Testing to Test Driven Modelling

TEST Huddle

Practical Testing Strategy for Agile Team

Jen-Chieh Ko

Tdd and-design-draft

PrabudhGupta1

Semelhante a My Laws of Test Driven Development (2023) (20)

How BDD enables True CI/CD

Effective Testing Practices in an Agile Environment

Journey of atdd

Test-Driven Development

Test Driven Development - Overview and Adoption

Introduction to Test Driven Development

Reduce Development Cost with Test Driven Development

Behavior Driven Development—A Guide to Agile Practices by Josh Eastman

Pega robotics best practices building solutions (1)

Pega Robotics Training @Phno: whatsapp @8142976573.

Test-Driven Design - ¿Porqué?

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

Getting a grip on your code dependencies

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

Building rich domain models with ddd and tdd ivan paulovich - betsson

How to Use Project Control 1.0

TDD and S.O.L.I.D.; Two Ingredients For High Quality Software

Darius Silingas - From Model Driven Testing to Test Driven Modelling

Practical Testing Strategy for Agile Team

Tdd and-design-draft

Mais de Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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#

Dennis Doomen

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)

Dennis Doomen

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!

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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)

Dennis Doomen

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

Dennis Doomen

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)

Dennis Doomen

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)

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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

Dennis Doomen

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, ...

Dennis Doomen

Mais de Dennis Doomen (20)

Tools and practices to help you deal with legacy code

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

Design patterns for Event Sourcing in .NET

Automate Infrastructure with Pulumi and C#

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

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

50 things software teams should not do.pptx

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

A lab around the principles and practices for writing maintainable code

How to Practice TDD Without Shooting Yourself in the Foot

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

Event Sourcing from the Trenches (DDD Europe 2020)

How to practice TDD without shooting yourself in the foot

Decomposing the Monolith (Riga Dev Days 2019)

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

Lessons learned from two decades of professional software development

The Good, The Bad and The Ugly of Event Sourcing

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

How To Practice TDD Without Shooting Yourself In The Foot

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

Último

Event-Driven Architecture Masterclass: Engineering a Robust, High-performance...

ScyllaDB

Introduction to FDO and How It works Applications _ Richard at FIDO Alliance.pdf

FIDO Alliance

Extensible Python: Robustness through Addition - PyCon 2024

Patrick Viafore

The Metaverse: Are We There Yet?

Mark Billinghurst

In today's digital world, trust is key to customer relationships, but keeping it is a huge challenge. Customers are well-informed and empowered, quick to change brands if their trust is broken, even if it costs them more. This puts a lot of pressure on organizations to handle trust and safety issues with great care and transparency. The challenge, however, is real. Fragmented solutions have left privacy, legal, and security teams in a perpetual cycle of catch-up, struggling to update privacy notices, manage customer data rights, and answer lengthy security questionnaires—all while trying to prove ROI to the business. It's a thankless job, filled with repetition, tedious tasks, and constant interdepartmental coordination. Combine this with fast regulatory changes and the quick evolution of AI, and it becomes overwhelming. Join this webinar to learn more about TrustArc's new innovative solution Trust Center, the only unified, no-code online hub for trust and safety information built for privacy, security, compliance, and legal teams. Trust Center streamlines your path to compliance, shortens the pre-sales cycle, and reduces both legal and regulatory risks, saving time, effort, and cost. This webinar will review: - Why companies are building unified Trust Centers for a robust privacy program. - How unified Trust Centers streamline sales cycles, ensure regulatory compliance, and reduce operational bottlenecks. - How compliance, legal, security, GRC, and privacy teams benefit from a unified Trust Center in terms of needs, pains, and outcomes. - How TrustArc Trust Center saves time and work while reducing legal, reputational, and compliance risk by effectively managing policies, notices, terms, and disclosures, and providing real-time updates on subprocessors.

TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...

TrustArc

Portal Kombat : extension du réseau de propagande russe

中央社

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

FIDO Alliance

Introduction to FIDO Authentication and Passkeys.pptx

FIDO Alliance

State of the Smart Building Startup Landscape 2024!

Memoori

In the ever-evolving landscape of data management, Zero-ETL is an approach that is reshaping how businesses handle and integrate their data. This webinar explores Zero-ETL, a paradigm shift from the traditional Extract, Transform, Load (ETL) process, offering a more streamlined, efficient, and real-time data integration method. We will begin with an introduction to the concept of Zero-ETL, including how it allows direct access to data in its native environment and real-time data transformation, providing up-to-date information with significantly reduced data redundancy. Next, we'll take you through several demonstrations showing how Zero-ETL can deliver real-time data and enable the free movement of data between systems. We will also discuss the various tools that support all aspects of Zero-ETL, providing attendees with an understanding of how they can adopt this innovative approach in their organizations. Lastly, the session will conclude with an interactive Q&A segment, allowing participants to gain deeper insights into how Zero-ETL can be tailored to their specific business needs and how they can get started today. Join us to discover how Zero-ETL can elevate your organization's data strategy.

The Zero-ETL Approach: Enhancing Data Agility and Insight

Safe Software

Tales from a Passkey Provider Progress from Awareness to Implementation.pptx

FIDO Alliance

Join me in this session where I'll share our journey of building a fully serverless application that flawlessly managed check-ins for an event with a staggering 80 thousand registrations. We'll dive into three key strategies that made this possible. Firstly, by harnessing DynamoDB global tables, we ensured global service availability and data replication across regions, boosting performance and disaster recovery. Next, we'll explore how we seamlessly integrated real-time updates into the app using Appsync subscriptions, making the experience dynamic and engaging for users. Finally, I'll discuss how provisioned concurrency not only improved performance but also kept costs in check, highlighting the cost-effectiveness of serverless architectures. Through these strategies and the inherent scalability of serverless technology, our application effortlessly handled massive user loads without manual intervention. This session is a real world example to the power and efficiency of modern cloud-based solutions in enabling seamless scalability and robust performance with Serverless

How we scaled to 80K users by doing nothing!.pdf

Srushith Repakula

Vector Search @ sw2con for slideshare.pptx

jbellis

Welcome to this session on UiPath Manufacturing and AI. In this session, we will discuss the importance UiPath plays with technology in the manufacturing and we will do an overview of AI and Document Understanding. Please join us to hear from UiPath and Community experts on why you might consider leveraging UiPath in manufacturing. Topics covered Community team overview The importance of UiPath technology for manufacturing UiPath AI and Document Understanding overview What is Document Understanding? DU Process Studio Template Components of DU Framework Q&A Speakers: Sebastian Seutter, Senior Industry Practice Director, UiPath, Inc. Priya Darshini, UiPath MVP RPA Solutions Architect Dzmitry Belanovski, Account Executive, UiPath, Inc.

UiPath manufacturing technology benefits and AI overview

DianaGray10

Intro to Passkeys and the State of Passwordless.pptx

FIDO Alliance

Hyatt driving innovation and exceptional customer experiences with FIDO passw...

FIDO Alliance

Ruby has a lot of standard libraries from Ruby 1.8. I promote them democratically with GitHub today via default and bundled gems. So, I'm working to extract them for Ruby 3.4 continuously and future versions. It's long journey for me. After that, some versions may suddenly happen LoadError at require when running bundle exec or bin/rails, for example matrix or net-smtp. We need to learn what's difference default/bundled gems with standard libraries. In this presentation, I will introduce what's the difficult to extract bundled gems from default gems and the details of the functionality that Ruby's require and bundle exec with default/bundled gems. You can learn how handle your issue about standard libraries.

Long journey of Ruby Standard library at RubyKaigi 2024

Hiroshi SHIBATA

Event-Driven Architecture Masterclass: Challenges in Stream Processing

ScyllaDB

Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...

ScyllaDB

AI mind or machine power point presentation

yogeshlabana357357

My Laws of Test Driven Development (2023)

1. Guidelines and heuristics that will help you reach the Plateau of Productivity My 25-ish “laws” of Test Driven Development Dennis Doomen @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

2. About Me Hands-on architect in the .NET space with 26 years of experience on an everlasting quest for knowledge to build the right software the right way at the right time @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

4. The Adoption Cycle for Test Driven Development @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

5. Design for Testability @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

6. Design class responsibilities Write first test Generate stubs Fail for the right reason Implement real deal Ensure test succeeds Identify alternative scenarios Repeat twice Refactor Start designing responsibilities before you write your first test

7. Then use the tests to drive the design further @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

8. Organize code by functionalities / capabilities

9. Use the Dependency Inversion Principle to decouple boundaries Order Processing IStoreOrders<T> + Query<T>(); + Add<T>(); + Delete<T>(); NHibernate Repository Order Processing IStoreOrders + GetIncompleteOrders(minValue); + StoreOrder(); + CompleteOrder(); OrderRepository VS @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

10. Apply DRY within those boundaries Duplicated Service 1 Duplicated Service 1 Duplicated Service 2 Duplicated Service 2 Duplicated Service 1 Centralized Service 3 Extension Methods Extension Methods Extension Methods Extension Methods Helpers Helpers Helpers Helpers

11. Use the right scope Dennis Doomen | @ddoomen | The Continuous Improver

12. Service Service Service Service Service Centralized Service Align your test scope with those “boundaries”

13. But sometimes, testing smaller is fine too Application Functional Slice Service Critical Internal Component Internal Component

14. Test things designed to reusable separately…

15. …but test implementation details as part of a bigger scope

16. Treat adjacent folders as separate boundaries

17. Test the real surface area

18. It’s fine to include the database

19. Clarify the arrange, act and assert

20. But use a different style if that helps

21. Don’t bother defining what “unit” vs “integration” is

22. Test guidelines Dennis Doomen | @ddoomen | The Continuous Improver

23. Write your tests like you write your production code

24. Allow your tests to be used as documentation

25. It’s fine to inject concrete classes inside boundaries @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

26. Use mocking between boundaries but avoid using them internally Service Service Service Service Service Centralized Service Can use mocking Can use mocking Can use mocking Can use mocking Avoid mocking Avoid mocking Avoid mocking @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

27. Don’t return mocks from mocks @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

28. Hide things that are not important for that specific test

29. Ensure it fails or succeeds for the right reason

30. Prefer inline literal strings and numbers over constants @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

31. Don’t use production code in assertions @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

32. Only assert what’s relevant for that specific test case @ddoomen | Principal Consultant | The Continuous Improver | Aviva Solutions

33. Keep out of the debugger hell

34. Naming and organization #avivasolutions

35. Postfix with Specs to emphasize tests are specifications

36. Group test by API or purpose using nested classes

37. Use short fact-based names.

38. Q&A (and win a 1-year license for the JetBrains Suite) …ping me at @ddoomen …email me at dennis.doomen@avivasolutions.nl

My Laws of Test Driven Development (2023)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a My Laws of Test Driven Development (2023)

Semelhante a My Laws of Test Driven Development (2023) (20)

Mais de Dennis Doomen

Mais de Dennis Doomen (20)

Último

Último (20)

My Laws of Test Driven Development (2023)