Andreas Lausen
Software Architect
Hildesheim, Germany
Actions
Andreas Lausen is a Software Architect at MEDIFOX DAN. His main focus is the design and implementation of long term maintainable and extensible systems. His tech stack is mostly NET. He also does Mobile Development on iOS and Android.
Andreas Lausen ist Software Architect bei der MEDIFOX DAN GmbH. Der Schwerpunkt seiner Tätigkeit liegt auf der Konzeption und Umsetzung von langfristig wart- und erweiterbaren Softwaresystemen. Als Technologien setzt er hauptsächlich .NET und die iOS und Android SDKs ein.
Area of Expertise
Topics
Legacy Code verbessern mit Unit Tests
Jeder Entwickler kennt diese Situation: man möchte Code ändern, der schwer änderbar ist. Unglücklicherweise existieren keine automatisierten Tests, sodass die Auswirkungen der Änderungen schwer zu überblicken sind.
Unit Tests können dabei helfen. In Projekten auf der grünen Wiese ist es kein Problem, Unit Tests von Anfang an zu berücksichtigen und den Code entsprechend testbar zu gestalten. Aber wie geht man vor, wenn man schlecht testbaren Code vorfindet?
In diesem Vortrag schauen wir uns Techniken und Methoden an, mit denen man nach und nach Legacy Code für bessere Testbarkeit umstrukturieren kann. Als Ergebnis erhalten wir besseren Code, für den wir gleichzeitig Unit Tests schreiben können, was uns als Entwickler Sicherheit bei der Änderung von Legacy Code zurückgibt.
Schnelle Integration Tests mit Entity Framework Core
Unit Tests bieten zahlreiche Vorteile. Sie schaffen Sicherheit für uns Entwickler, weil wir sie jederzeit schnell ausführen können und sofort sehen, ob wir etwas kaputt gemacht haben, wenn wir Details einer Implementierung ändern.
Aber Moment: wieso brechen in bestimmten Fällen ständig unsere Tests, obwohl wir nur Implementierungsdetails geändert haben, nicht jedoch das öffentliche Verhalten einer Methode? Insbesondere dann, wenn eine Methode viele Methoden anderer Klassen aufruft, und man in Unit Tests den Aufruf dieser Methoden mit Mocks testet, entsteht schnell dieses Problem. Die Unit Tests bieten nun keine Sicherheit mehr und haben wenig Nutzen, da sie Implementierungsdetails testen und damit genau das tun, wofür sie nicht gedacht und nicht geeignet sind. Eigentlich wollen wir doch Änderungen vornehmen können, ohne dass die Tests brechen, wenn sich die öffentliche Schnittstelle nicht ändert.
Als Alternative zu Unit Tests kommen in solchen Fällen Integration Tests infrage. Die haben den Ruf, dass sie langsam und fehleranfällig sind, weil sie meistens eine echte Datenbank verwenden.
Aber das muss nicht sein. Im .NET Umfeld bietet Entity Framework Core eine interessante Möglichkeit, Integration Tests umzusetzen, die fast genau so schnell laufen wie Unit Tests. Damit erreichen wir, dass wir in dem oben beschriebenen Szenario Sicherheit zurückgewinnen, ohne dass wir Abstriche bei der Ausführungsgeschwindigkeit machen müssen.
In diesem Vortrag wird zunächst das beschriebene Problem anhand eines Code Beispiels erläutert. Anschließend wird im Live Coding demonstriert, wie sich schnelle Integration Tests konkret mit .NET, C# und Entity Framework Core umsetzen lassen.
Unit Tests - Grundlagen und Best Practices
Unit Testing Frameworks existieren seit über 20 Jahren. Dennoch schreiben viele Entwickler auch im Jahr 2024 immer noch nicht regelmäßig Unit Tests. Die Gründe dafür sind vielfältig.
Mit diesem Vortrag möchte ich Entwickler, die wenig Erfahrung mit Unit Testing haben, motivieren, sich näher mit dem Thema zu beschäftigen und sich die zahlreichen Vorteile zunutze zu machen.
Der Vortrag beginnt mit einer Einführung in das Thema Unit Testing. Es wird definiert, was Unit Tests sind, und eine Abgrenzung gegenüber anderen Arten von Tests (z.B. Integration Tests) vorgenommen. Außerdem wird der Nutzen von Unit Tests erläutert. Es wird kurz auf Test-Driven Development und den Zusammenhang mit Unit Tests eingegangen.
Weiterhin wird der Aufbau von Unit Tests erläutert und an einem kleinen Beispiel live demonstriert. Dabei wird auch darauf eingegangen, wie man Unit Tests benennt und wie man den Quellcode organisiert.
Es gibt drei verschiedene Arten von Unit Tests. Diese werden im Einzelnen erläutert.
Der nächste Abschnitt beschäftigt sich mit dem Umgang mit Abhängigkeiten in Unit Tests. Es wird erläutert, wie man in Unit Tests Abhängigkeiten durch Attrappen ersetzt und welche Arten von Attrappen es gibt. Es wird auf Frameworks eingegangen, die das Erstellen von Attrappen vereinfachen.
Im weiteren Verlauf werden Eigenschaften guter Unit Tests aufgezählt und erläutert. Diese sind wichtig, um einen möglichst großen Nutzen aus Unit Tests zu ziehen, denn gar keine Unit Tests sind oft besser als schlechte Unit Tests.
Es wird außerdem der Zusammenhang zwischen Unit Testing und Software Design erläutert.
Es gibt Situationen, in denen wir mit Unit Tests an Grenzen stoßen. Auch darauf wird eingegangen und es werden Alternativen vorgestellt. Danach sollte klar sein, dass Unit Tests zwar sehr wichtig sind, aber nicht ausreichen, um die Funktion und Qualität komplexer Softwaresysteme sicherzustellen.
Am Ende des Vortrags wird ein Ausblick darauf gegeben, wie man in Legacy Projekten mit Unit Testing starten kann.
Schneller (und besser?) Unit Tests schreiben mit KI
Unit Tests sind ein wichtiger Bestandteil einer jeden Testsuite. Sie zu schreiben macht Spaß, beinhaltet aber auch viele repititive Tätigkeiten.
KI Assistenten wie GitHub Copilot sind nun schon einige Zeit am Markt und vieles wurde bereits darüber berichtet.
In diesem Vortrag wollen wir herausfinden, inwieweit uns KI Assistenten beim Schreiben von Unit Tests unterstützen können. Unser Ziel ist vor allem Zeit zu sparen, ohne dabei die Qualität der Tests zu vernachlässigen.
Wir halten uns nicht lange mit der Theorie auf, sondern steigen direkt in konkrete Codebeispiele ein. Die Beispiele sind in C# und als KI Assistent wird GitHub Copilot eingesetzt.
Besser testen mit Akzeptanztests
Unit Tests sind ein wichtiger Bestandteil einer jeden Testsuite. Sie werden von Entwicklern für Entwickler geschrieben und testen den Code auf der untersten Ebene. Das ist gut und wichtig, hat aber auch seine Grenzen. Man kann vor allem mit Unit Tests nicht sicherstellen, dass das richtige Feature umgesetzt bzw. ein Feature richtig umgesetzt wurde.
Hier setzen Akzeptanztests an. Diese stehen in der Testpyramide eine Ebene über den Unit Tests. Im Gegensatz zu Unit Tests können Akzeptanztests auch von Nicht-Entwicklern in einer formalen, natürlichen Sprache geschrieben werden. Ein Akzeptanztests beschreibt jeweils konkrete Beispiele von Use Cases. Mit entsprechenden Tools werden diese automatisiert ausführbar gemacht. Man erhält eine ausführbare Spezifikation. Manuelle Regressionstests gehören damit der Vergangenheit an.
Durch dieses Vorgehen, das auch als Behaviour-Driven Development (BDD) bezeichnet wird, wird auch die Zusamenarbeit zwischen Entwicklern und anderen Stakeholdern gefördert. Nebenbei kann eine lebende Dokumentation generiert werden, in der jederzeit für jeden ersichtlich ist, welche Features bereits umgesetzt sind und funktionieren und was noch nicht umgesetzt ist bzw. nicht funktioniert.
In diesem Vortrag schauen wir uns die Grundlagen von Behaviour-Driven Development (BDD) und Akzeptanztests an. Anschließend sehen wir uns an einem konkreten Beispiel an wie sich Akzeptanztests in .NET mit SpecFlow umsetzen lassen.
Teste deine Architektur!
Wir alle kennen das: am Anfang eines Softwareentwicklungsprojektes macht man sich Gedanken über Architektur, Bausteine, Abhängigkeiten und solche Dinge. Dann läuft man los und implementiert. Anfangs ist die Produktivität hoch. Doch der Code wird immer mehr und die Anforderungen werden komplexer. Es schleichen sich ungewollte Abhängigkeiten ein. Eine Referenz ist nun mal in modernen Entwicklungsumgebungen schnell hinzugefügt. Im Laufe der Zeit weicht man ohne es zu merken immer weiter von der ursprünglich entworfenen Architektur ab. Architekturdiagramme und Code passen nicht mehr zusammen. Das lässt sich auch mit Clean Code, Test-driven Development und regelmäßigen Architekturreviews nicht immer verhindern.
Eine Möglichkeit, dem entgegenzuwirken, sind Architekturtests. Die funktionieren wie Unit Tests, testen aber keine funktionalen Anforderungen, sondern nichtfunktionale bzw. Qualitätsanforderungen. Tools sind als Open Source für Java und .NET verfügbar. Der Einstieg ist leicht. Architekturtests können automatisiert im Continuous Build laufen und verhindern dadurch, dass sich Verstöße gegen die anfangs aufgestellten Architekturregeln einschleichen.
Dieser Vortrag gibt einen Überblick darüber, was mit Architekturtests alles möglich ist. Anhand einer Beispielarchitektur, die an das taktische Design aus dem Domain-Driven Design angelehnt ist, wird demonstiert, wie sich verschiedene Aspekte der Architektur testen lassen.
Domain-Driven Design für Einsteiger
Softwareentwickler lösen Probleme gerne mit Technik. Anforderungen werden umgesetzt, ohne viel mit dem Anwender zu kommunizieren, und ohne immer das Problem des Anwenders zu verstehen, das die Software lösen soll. Durch fehlende fachliche Schnitte entsteht ein Big Ball of Mud, in dem alles voneinander abhängig ist und die Kosten für die Weiterentwicklung schnell steigen. Irgendwann ist eine technische Komplexität erreicht, die niemand mehr beherrschen kann.
Domain-Driven Design ist ein Ansatz, um dem Big Ball of Mud langfristig entgegenzuwirken. Im Vordergrund steht die Zusammenarbeit mit den Fachexperten sowie der Fokus auf klar voneinander abgegrenzte Teilsysteme.
Dieser Vortrag richtet sich an Einsteiger, die bisher keine Erfahrung mit diesem umfangreichen Thema gemacht haben. Er bietet einen leicht verständlichen Überblick über die wesentlichen Inhalte des Strategic Design, Tactical Design und Collaborative Modeling. Am Ende haben die Teilnehmer ein Grundverständnis von Domain-Driven Design und kennen alle wichtigen Konzepte.
Writing unit tests faster (and better?) with AI
Unit tests are the foundation of every test suite. It can be fun to write them, but often it becomes a repetitive task quickly.
AI assistents like GitHub Copilot have been around for a while and have been covered widely.
This session focuses on the question of how we can leverage AI assistents to write unit tests faster without compromisung the test quality.
This is a very practical session. We will dive right into concrete examples in C# code. For AI assistance we will use GitHub Copilot.
Beyond Unit Testing: Embracing Acceptance Tests for Better Quality
Unit tests are an essential part of any test suite. Written by developers for developers, they test the code at the lowest level. While unit tests are great for verifying individual components, they may not reflect the system's behavior in real-world scenarios. Above all, unit tests cannot ensure that the correct feature has been implemented or that a feature has been implemented correctly. This is where acceptance tests come into play, designed from the user's perspective to ensure the system meets their requirements and expectations. Positioned one level above unit tests in the testing pyramid, acceptance tests can be written by non-developers in a formal, natural language, describing specific examples of use cases. With the appropriate tools, these can be made automatically executable, resulting in an executable specification and rendering manual regression tests a thing of the past. This approach, also called Behaviour-Driven Development (BDD), facilitates a shared understanding of requirements through a common language, bridging the gap between technical and non-technical team members. Additionally, a living documentation can be generated, which makes it clear for everyone at any time which features have already been implemented and are working and what has not yet been implemented or does not work.
In this talk, we will explore the basics of BDD and acceptance tests. Then, using a concrete example, we will demonstrate how acceptance tests can be implemented in .NET with SpecFlow, providing attendees with actionable knowledge on integrating these practices into their projects.
BED-Con 2023 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top