What is the right unit in unit testing (UpdateConf 2022)
•Als PPTX, PDF herunterladen•
0 gefällt mir•104 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
Melden
Teilen
Melden
Teilen
Empfohlen
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.
Test Driven Development - Overview and Adoption
Test-driven development (TDD) is a software development technique where unit tests are written before code to define desired functionality. Writing tests first helps produce code with better design, lower maintenance costs, and fewer bugs. Key principles of TDD include writing code only to pass failing tests and eliminating duplication. Benefits include better test coverage, easier refactoring, and preventing regressions. TDD helps developers act as users to define behavior through interactions between system components.
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 afterIranian Domain-Driven Design Community
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.JavaScript Unit Testing
Presentation developed for JSChannel BLR :: Meetup 8 - Unit testing AngularJS using Jasmine and Karma
Unit Testing, TDD and the Walking Skeleton
The document discusses unit testing, test-driven development (TDD), and the walking skeleton approach. It provides an overview of these software development practices, including writing automated tests before code, using the tests to drive code development, and starting projects with an initial architecture or "walking skeleton" that is automatically testable, buildable, and deployable. The document aims to dispel common myths about testing and convince readers of the value of these practices.
How to Deliver the Right Software (Specification by example)
Talk about Specification by Example. What's the problems it tries to tackle and how to solve them.
I gave this talk at findmypast.com on a "lunch and learn" weekly meeting for the company.
This is a new version of my previous presentation about "Specification by example"
http://www.slideshare.net/AsierBarrenetxea1/specification-by-example-33594438
Software Design for Testability
This document discusses design for testability. It defines testability as having controllability and visibility. Controllability is the ability to apply inputs and place a system in specified states, while visibility is the ability to observe states and outputs. The document outlines why testability is important for improving quality and reducing costs. It describes how to achieve testability through good design practices like abstraction, encapsulation, and avoiding interdependence. Testability features like logging and assertions are also recommended. Development techniques like defensive programming, design by contract, and test-driven development can further enhance testability.
Test-Driven Development
Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle of requirements, design, and coding. It promotes writing tests before writing code (test-first design) and helps improve code quality by reducing defects. The TDD cycle involves writing an automated test, running the test and seeing it fail, writing the minimum amount of code to pass the test, and refactoring the code as needed. TDD brings benefits like clarifying requirements, adding executable documentation, and detecting errors early. Acceptance TDD involves automating acceptance tests to define and validate requirements. It helps establish a definition of done and improves team collaboration.
Empfohlen
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.
Test Driven Development - Overview and Adoption
Test-driven development (TDD) is a software development technique where unit tests are written before code to define desired functionality. Writing tests first helps produce code with better design, lower maintenance costs, and fewer bugs. Key principles of TDD include writing code only to pass failing tests and eliminating duplication. Benefits include better test coverage, easier refactoring, and preventing regressions. TDD helps developers act as users to define behavior through interactions between system components.
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 afterIranian Domain-Driven Design Community
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.JavaScript Unit Testing
Presentation developed for JSChannel BLR :: Meetup 8 - Unit testing AngularJS using Jasmine and Karma
Unit Testing, TDD and the Walking Skeleton
The document discusses unit testing, test-driven development (TDD), and the walking skeleton approach. It provides an overview of these software development practices, including writing automated tests before code, using the tests to drive code development, and starting projects with an initial architecture or "walking skeleton" that is automatically testable, buildable, and deployable. The document aims to dispel common myths about testing and convince readers of the value of these practices.
How to Deliver the Right Software (Specification by example)
Talk about Specification by Example. What's the problems it tries to tackle and how to solve them.
I gave this talk at findmypast.com on a "lunch and learn" weekly meeting for the company.
This is a new version of my previous presentation about "Specification by example"
http://www.slideshare.net/AsierBarrenetxea1/specification-by-example-33594438
Software Design for Testability
This document discusses design for testability. It defines testability as having controllability and visibility. Controllability is the ability to apply inputs and place a system in specified states, while visibility is the ability to observe states and outputs. The document outlines why testability is important for improving quality and reducing costs. It describes how to achieve testability through good design practices like abstraction, encapsulation, and avoiding interdependence. Testability features like logging and assertions are also recommended. Development techniques like defensive programming, design by contract, and test-driven development can further enhance testability.
Test-Driven Development
Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle of requirements, design, and coding. It promotes writing tests before writing code (test-first design) and helps improve code quality by reducing defects. The TDD cycle involves writing an automated test, running the test and seeing it fail, writing the minimum amount of code to pass the test, and refactoring the code as needed. TDD brings benefits like clarifying requirements, adding executable documentation, and detecting errors early. Acceptance TDD involves automating acceptance tests to define and validate requirements. It helps establish a definition of done and improves team collaboration.
Testing practicies not only in scala
The presentation describes testing techniques which have been successfully applied in commercial Scala projects.
TDD in PHP - Memphis PHP 2011-08-25
The document is a presentation about test-driven development (TDD) in PHP. It introduces TDD and the speaker, defines the TDD process, lists benefits and drawbacks, and demonstrates a live coding example of using TDD to build a calculator and tutor class. The example shows writing tests first, then code to pass the tests, and refactoring with confidence due to the tests. The goals are to provide a practical TDD example and demonstrate how TDD impacts design decisions.
50 things software teams should not do.pptx
The document discusses 50 things that software teams should avoid doing related to architecture, code design, testability, documentation, team maturity and process. Some examples include treating a monolith as inherently bad, using microservices as an escape plan from technical debt, dogmatically using design patterns, insufficient test coverage, messy source control history, developers working in isolation, artificial sprint goals, and long-running stand-ups. The document is written by Dennis Doomen, an architect with 25 years of experience in the .NET space.
Pair Programming
This document provides an overview of pair programming and discusses its benefits. It defines pair programming as two developers working together at one computer, with one typing code as the "driver" and the other reviewing the work and providing feedback as the "navigator". Research has found that pair programming can result in 15% fewer bugs and slightly better design quality compared to solo work. Benefits include improved learning, quality, focus, motivation and morale. The document also covers challenges, tips, and different pairing patterns like driver-navigator and ping-pong pairing.
Tdd
Test-driven development (TDD) is a software development process that relies on the repetition of short development cycles called red-green-refactor cycles. In TDD, tests are written before code to define desired functionality, and then code is written to pass those tests; this is followed by refactoring. The benefits of TDD include producing code that is robust, well-designed, and with fewer bugs due to comprehensive test coverage. While TDD requires discipline, it helps ensure code works as intended and allows refactoring with confidence that changes don't break existing functionality. Some potential vulnerabilities of TDD are that it may not prevent wrong solutions if requirements are unclear, can be difficult for UI or database-dependent programs
Refactoring for Software Design Smells - 1 day Workshop
The document discusses various design smells that negatively impact software quality attributes like reusability, changeability, understandability and extensibility. It covers different categories of design smells including abstraction smells, encapsulation smells and modularization smells. Some examples of specific smells discussed are missing abstraction, leaky encapsulation, broken modularization etc. The document emphasizes the importance of addressing design smells through refactoring to improve design quality and reduce technical debt.
A Case Of Artful Exploration
The document summarizes an agile project to extend an open source software platform for a client. Key challenges included establishing collaboration between different teams, estimating iteration costs for exploration and prototyping activities, and determining the appropriate testing approach given the need to balance exploring new features with ensuring existing functionality and requirements were still met. Overall the project converged as expected around the fourth sprint and the client was satisfied with balancing costs, effort, and delivered functionality through an iterative approach, even though complexity remained unknown.
Up to speed in domain driven design
This document discusses Domain Driven Design (DDD). It provides an overview of DDD, including that it focuses on removing translation barriers between a domain, development team, and software design. It also describes common building blocks of domain models such as entities, value objects, factories, repositories, and services. Additionally, it discusses refactoring a model to gain deeper insight, including making implicit concepts explicit.
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
The document discusses the authors' experience with different testing strategies at their company StratEx. They initially used Selenium for UI testing but found it did not help when they frequently changed screens. They then investigated Test-Driven Development (TDD) but found it inefficient, as tests are also code that must be written and maintained. Behavior-Driven Development (BDD) showed more promise as it focuses on functionality rather than architecture and bridges communication between users and developers. However, no methodology fully describes large, complex systems. The search for the best testing approach is ongoing.
Automated+Testing+Vs+Manual+Testing
Manual testing takes more effort and cost than automated testing. It is more boring and provides limited visibility compared to automated testing. Automated tests can test individual units of code, are reusable, and provide a safety net for refactoring. They also ensure all tests are run, drive clean design, and do not create code clutter like manual tests. However, the initial learning curve and effort to set up automated testing prevents some from adopting it. With proper tooling and process, these barriers can be overcome.
Automated Testing vs Manual Testing
From http://wiki.directi.com/x/AgAa - This is a 24 slide internal presentation covering virtues of Automated Testing vs Manual Testing. Inkeeping with our agile adoption this presentation covers various advantages (11 to be specific) obtained in using TDD and Automated Testing as opposed to Manual Testing
Automated Testing vs Manual Testing
Manual testing takes more effort and cost than automated testing. It is more boring and provides limited visibility for stakeholders. Automated tests can test single units, are reusable, and provide a safety net for refactoring. They also ensure all tests are run, drive clean design, and do not create code clutter like manual tests. An initial learning curve and questions around organization and reuse may prevent developers from writing automated tests, but designating responsibility and learning tools can help overcome these issues.
Improve your TDD skills
An amazing opportunity for all the coders to improve their TDD skills in a safe and thrilling environment. Our lab is a 3 hours intensive practice event, focusing on the practice of TDD, essential for software development and design, away from the pressures of ‘getting things done’.
xTreme Programming by Sejo Ćesić and Enis Zeherović
Introduction to eXtreme Programming (XP) with interactive and practical examples of one of its main practices: Test Driven Development (TDD).
In the first part, we will lead you through the practices of XP and make you understand why XP has been revolutionary for the software development.
After that, we will provide a more in-depth view of TDD. By sharing the best practices we will give you concrete guidelines on how to apply TDD on your projects. The session is expected to be highly interactive, you are all welcome to bring your own ideas, questions and suggestions.
Agile xp crash_course_2010_05_21
This document provides an overview of Agile and eXtreme Programming (XP), including the core values and principles of the Agile Manifesto, roles and practices in XP, and how to adopt and apply XP to projects. It discusses key aspects of XP like short iterations, user stories, frequent releases, test-driven development, refactoring, collective code ownership, and more. The goal is to give the reader a crash course in Agile and XP methodologies.
Bridging the communication gap
This document discusses using agile acceptance tests (AAT) to improve communication between business, development, and testing teams by moving business rules and requirements into automated tests. AAT involve collaboratively building examples during specification workshops that serve as both requirements and tests. This ensures the software meets customer expectations and focuses development. AAT provide benefits like early detection of gaps, improved understanding across roles, and living documentation of the project.
Agile principles and practices
Agile * Agile Principles * Agile Practices * Pair Programming * Extreme Programming * SOLID design principles * SDLC * Software Development
After working 10 years in multiple major "from-scratch" development projects, I finally got a chance to work in a truly Agile development project. Here is my take on how to make Agile work for your project.
Test-Driven Design - ¿Porqué?
The document discusses test-driven development (TDD) and how it can be used to reduce unnecessary complexity, also known as inventory, in software design. TDD involves writing automated tests before code to articulate requirements and ensure only needed code is written. It promotes designing simple, clear code without duplication through principles like You Aren't Gonna Need It and refactoring code in small, reversible steps. Following TDD principles is claimed to reduce inventory created by excess complexity and allow designs to evolve incrementally based on test feedback.
Introduction to Extreme Programming
This document provides an introduction and overview of eXtreme Programming (XP), an agile software development methodology. It discusses what XP is, its history and origins, core values and principles, practices, and components like the whole XP team. Key aspects of XP covered include pair programming, short development cycles, test-first development, simple design, frequent integration and feedback. The document aims to explain the philosophy and mechanics of the XP methodology.
Getting a grip on your code dependencies (2023-10)
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
Tools and practices to help you deal with legacy code
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
Weitere ähnliche Inhalte
Ähnlich wie What is the right unit in unit testing (UpdateConf 2022)
Testing practicies not only in scala
The presentation describes testing techniques which have been successfully applied in commercial Scala projects.
TDD in PHP - Memphis PHP 2011-08-25
The document is a presentation about test-driven development (TDD) in PHP. It introduces TDD and the speaker, defines the TDD process, lists benefits and drawbacks, and demonstrates a live coding example of using TDD to build a calculator and tutor class. The example shows writing tests first, then code to pass the tests, and refactoring with confidence due to the tests. The goals are to provide a practical TDD example and demonstrate how TDD impacts design decisions.
50 things software teams should not do.pptx
The document discusses 50 things that software teams should avoid doing related to architecture, code design, testability, documentation, team maturity and process. Some examples include treating a monolith as inherently bad, using microservices as an escape plan from technical debt, dogmatically using design patterns, insufficient test coverage, messy source control history, developers working in isolation, artificial sprint goals, and long-running stand-ups. The document is written by Dennis Doomen, an architect with 25 years of experience in the .NET space.
Pair Programming
This document provides an overview of pair programming and discusses its benefits. It defines pair programming as two developers working together at one computer, with one typing code as the "driver" and the other reviewing the work and providing feedback as the "navigator". Research has found that pair programming can result in 15% fewer bugs and slightly better design quality compared to solo work. Benefits include improved learning, quality, focus, motivation and morale. The document also covers challenges, tips, and different pairing patterns like driver-navigator and ping-pong pairing.
Tdd
Test-driven development (TDD) is a software development process that relies on the repetition of short development cycles called red-green-refactor cycles. In TDD, tests are written before code to define desired functionality, and then code is written to pass those tests; this is followed by refactoring. The benefits of TDD include producing code that is robust, well-designed, and with fewer bugs due to comprehensive test coverage. While TDD requires discipline, it helps ensure code works as intended and allows refactoring with confidence that changes don't break existing functionality. Some potential vulnerabilities of TDD are that it may not prevent wrong solutions if requirements are unclear, can be difficult for UI or database-dependent programs
Refactoring for Software Design Smells - 1 day Workshop
The document discusses various design smells that negatively impact software quality attributes like reusability, changeability, understandability and extensibility. It covers different categories of design smells including abstraction smells, encapsulation smells and modularization smells. Some examples of specific smells discussed are missing abstraction, leaky encapsulation, broken modularization etc. The document emphasizes the importance of addressing design smells through refactoring to improve design quality and reduce technical debt.
A Case Of Artful Exploration
The document summarizes an agile project to extend an open source software platform for a client. Key challenges included establishing collaboration between different teams, estimating iteration costs for exploration and prototyping activities, and determining the appropriate testing approach given the need to balance exploring new features with ensuring existing functionality and requirements were still met. Overall the project converged as expected around the fourth sprint and the client was satisfied with balancing costs, effort, and delivered functionality through an iterative approach, even though complexity remained unknown.
Up to speed in domain driven design
This document discusses Domain Driven Design (DDD). It provides an overview of DDD, including that it focuses on removing translation barriers between a domain, development team, and software design. It also describes common building blocks of domain models such as entities, value objects, factories, repositories, and services. Additionally, it discusses refactoring a model to gain deeper insight, including making implicit concepts explicit.
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
The document discusses the authors' experience with different testing strategies at their company StratEx. They initially used Selenium for UI testing but found it did not help when they frequently changed screens. They then investigated Test-Driven Development (TDD) but found it inefficient, as tests are also code that must be written and maintained. Behavior-Driven Development (BDD) showed more promise as it focuses on functionality rather than architecture and bridges communication between users and developers. However, no methodology fully describes large, complex systems. The search for the best testing approach is ongoing.
Automated+Testing+Vs+Manual+Testing
Manual testing takes more effort and cost than automated testing. It is more boring and provides limited visibility compared to automated testing. Automated tests can test individual units of code, are reusable, and provide a safety net for refactoring. They also ensure all tests are run, drive clean design, and do not create code clutter like manual tests. However, the initial learning curve and effort to set up automated testing prevents some from adopting it. With proper tooling and process, these barriers can be overcome.
Automated Testing vs Manual Testing
From http://wiki.directi.com/x/AgAa - This is a 24 slide internal presentation covering virtues of Automated Testing vs Manual Testing. Inkeeping with our agile adoption this presentation covers various advantages (11 to be specific) obtained in using TDD and Automated Testing as opposed to Manual Testing
Automated Testing vs Manual Testing
Manual testing takes more effort and cost than automated testing. It is more boring and provides limited visibility for stakeholders. Automated tests can test single units, are reusable, and provide a safety net for refactoring. They also ensure all tests are run, drive clean design, and do not create code clutter like manual tests. An initial learning curve and questions around organization and reuse may prevent developers from writing automated tests, but designating responsibility and learning tools can help overcome these issues.
Improve your TDD skills
An amazing opportunity for all the coders to improve their TDD skills in a safe and thrilling environment. Our lab is a 3 hours intensive practice event, focusing on the practice of TDD, essential for software development and design, away from the pressures of ‘getting things done’.
xTreme Programming by Sejo Ćesić and Enis Zeherović
Introduction to eXtreme Programming (XP) with interactive and practical examples of one of its main practices: Test Driven Development (TDD).
In the first part, we will lead you through the practices of XP and make you understand why XP has been revolutionary for the software development.
After that, we will provide a more in-depth view of TDD. By sharing the best practices we will give you concrete guidelines on how to apply TDD on your projects. The session is expected to be highly interactive, you are all welcome to bring your own ideas, questions and suggestions.
Agile xp crash_course_2010_05_21
This document provides an overview of Agile and eXtreme Programming (XP), including the core values and principles of the Agile Manifesto, roles and practices in XP, and how to adopt and apply XP to projects. It discusses key aspects of XP like short iterations, user stories, frequent releases, test-driven development, refactoring, collective code ownership, and more. The goal is to give the reader a crash course in Agile and XP methodologies.
Bridging the communication gap
This document discusses using agile acceptance tests (AAT) to improve communication between business, development, and testing teams by moving business rules and requirements into automated tests. AAT involve collaboratively building examples during specification workshops that serve as both requirements and tests. This ensures the software meets customer expectations and focuses development. AAT provide benefits like early detection of gaps, improved understanding across roles, and living documentation of the project.
Agile principles and practices
Agile * Agile Principles * Agile Practices * Pair Programming * Extreme Programming * SOLID design principles * SDLC * Software Development
After working 10 years in multiple major "from-scratch" development projects, I finally got a chance to work in a truly Agile development project. Here is my take on how to make Agile work for your project.
Test-Driven Design - ¿Porqué?
The document discusses test-driven development (TDD) and how it can be used to reduce unnecessary complexity, also known as inventory, in software design. TDD involves writing automated tests before code to articulate requirements and ensure only needed code is written. It promotes designing simple, clear code without duplication through principles like You Aren't Gonna Need It and refactoring code in small, reversible steps. Following TDD principles is claimed to reduce inventory created by excess complexity and allow designs to evolve incrementally based on test feedback.
Introduction to Extreme Programming
This document provides an introduction and overview of eXtreme Programming (XP), an agile software development methodology. It discusses what XP is, its history and origins, core values and principles, practices, and components like the whole XP team. Key aspects of XP covered include pair programming, short development cycles, test-first development, simple design, frequent integration and feedback. The document aims to explain the philosophy and mechanics of the XP methodology.
Ähnlich wie What is the right unit in unit testing (UpdateConf 2022) (20)
Refactoring for Software Design Smells - 1 day Workshop
Refactoring for Software Design Smells - 1 day Workshop
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
Test-Driven Developments are Inefficient; Behavior-Driven Developments are a ...
xTreme Programming by Sejo Ćesić and Enis Zeherović
xTreme Programming by Sejo Ćesić and Enis Zeherović
Mehr von Dennis Doomen
Getting a grip on your code dependencies (2023-10)
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
Tools and practices to help you deal with legacy code
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
What you can learn from an open-source project with 250 million downloads
Dennis Doomen presented on FluentAssertions, an open source .NET library for validation of results and state. With over 244 million downloads, it is successful due to its clean code design using test-driven development, extensibility, clear documentation, and support. Doomen discussed tools, practices, and principles from the project, including editorconfig, Roslyn analyzers, approval tests, GitHub Actions, and semantic versioning that can be applied to other projects.
Getting a grip on your code dependencies
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.
My Laws of Test Driven Development (2023)
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.
Design patterns for Event Sourcing in .NET
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.
Automate Infrastructure with Pulumi and C#
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.
Slow Event Sourcing (re)projections - Just make them faster!
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.
A lab around the principles and practices for writing maintainable code
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.
How to Practice TDD Without Shooting Yourself in the Foot
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.
Decomposing the Monolith using modern-day .NET and a touch of microservices
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.
Event Sourcing from the Trenches (DDD Europe 2020)
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.
Practical introduction to DDD, CQRS and Event Sourcing
The document discusses various challenges and solutions related to building applications using an event-driven architecture and event sourcing approach. It addresses issues like handling schema changes, dealing with bugs in projections, improving performance of rebuilding projections, handling archiving of large amounts of historical data, and enhancing events with additional context like original names. Various database technologies and patterns are discussed as solutions, such as using different storage for projections, stream tombstoning, and event modifiers.
How to practice TDD without shooting yourself in the foot
The document discusses test-driven development (TDD) and provides an opinionated definition and guidelines for TDD. It defines TDD as designing class responsibilities, writing an initial unit test, generating code stubs, ensuring the test fails, implementing the code, ensuring the test succeeds, identifying alternative scenarios, and repeating the process twice before refactoring. It also provides examples of code organization for TDD and recommends keeping tests focused on relevant parts of the code and avoiding debugger use. External resources on effective TDD practices are referenced.
Decomposing the Monolith (Riga Dev Days 2019)
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.
A lab around the principles and practices for writing maintainable code (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.
Lessons learned from two decades of professional software development
Dennis Doomen discusses key principles for maintainable code, including isolation, testability, being diagnosable, traceability, readability, and discoverability. The goal is code that can be changed confidently by any developer on a team without fear and has a low cognitive load for readers to understand. Dennis Doomen is focused on continuously improving code through these principles.
The Good, The Bad and The Ugly of Event Sourcing
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.
Event Sourcing from the Trenches (with examples from .NET)
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.
How To Practice TDD Without Shooting Yourself In The Foot
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.
Mehr von Dennis Doomen (20)
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
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
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
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
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
How to practice TDD without shooting yourself in the foot
How to practice TDD without shooting yourself in the foot
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
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
Kürzlich hochgeladen
International Conference on NLP, Artificial Intelligence, Machine Learning an...
International Conference on NLP, Artificial Intelligence, Machine Learning and Applications (NLAIM 2024) offers a premier global platform for exchanging insights and findings in the theory, methodology, and applications of NLP, Artificial Intelligence, Machine Learning, and their applications. The conference seeks substantial contributions across all key domains of NLP, Artificial Intelligence, Machine Learning, and their practical applications, aiming to foster both theoretical advancements and real-world implementations. With a focus on facilitating collaboration between researchers and practitioners from academia and industry, the conference serves as a nexus for sharing the latest developments in the field.
artificial intelligence and data science contents.pptx
What is artificial intelligence? Artificial intelligence is the ability of a computer or computer-controlled robot to perform tasks that are commonly associated with the intellectual processes characteristic of humans, such as the ability to reason.
› ...
Artificial intelligence (AI) | Definitio
原版制作(Humboldt毕业证书)柏林大学毕业证学位证一模一样
原件一模一样【微信：bwp0011】《(Humboldt毕业证书)柏林大学毕业证学位证》【微信：bwp0011】学位证，留信认证（真实可查，永久存档）原件一模一样纸张工艺/offer、雅思、外壳等材料/诚信可靠,可直接看成品样本，帮您解决无法毕业带来的各种难题！外壳，原版制作，诚信可靠，可直接看成品样本。行业标杆！精益求精，诚心合作，真诚制作！多年品质 ,按需精细制作，24小时接单,全套进口原装设备。十五年致力于帮助留学生解决难题，包您满意。
本公司拥有海外各大学样板无数，能完美还原。
1:1完美还原海外各大学毕业材料上的工艺：水印，阴影底纹，钢印LOGO烫金烫银，LOGO烫金烫银复合重叠。文字图案浮雕、激光镭射、紫外荧光、温感、复印防伪等防伪工艺。材料咨询办理、认证咨询办理请加学历顾问微bwp0011
【主营项目】
一.毕业证【微bwp0011】成绩单、使馆认证、教育部认证、雅思托福成绩单、学生卡等！
二.真实使馆公证(即留学回国人员证明,不成功不收费)
三.真实教育部学历学位认证（教育部存档！教育部留服网站永久可查）
四.办理各国各大学文凭(一对一专业服务,可全程监控跟踪进度)
如果您处于以下几种情况：
◇在校期间，因各种原因未能顺利毕业……拿不到官方毕业证【微bwp0011】
◇面对父母的压力，希望尽快拿到；
◇不清楚认证流程以及材料该如何准备；
◇回国时间很长，忘记办理；
◇回国马上就要找工作，办给用人单位看；
◇企事业单位必须要求办理的
◇需要报考公务员、购买免税车、落转户口
◇申请留学生创业基金
留信网认证的作用:
1:该专业认证可证明留学生真实身份
2:同时对留学生所学专业登记给予评定
3:国家专业人才认证中心颁发入库证书
4:这个认证书并且可以归档倒地方
5:凡事获得留信网入网的信息将会逐步更新到个人身份内，将在公安局网内查询个人身份证信息后，同步读取人才网入库信息
6:个人职称评审加20分
7:个人信誉贷款加10分
8:在国家人才网主办的国家网络招聘大会中纳入资料，供国家高端企业选择人才
Use PyCharm for remote debugging of WSL on a Windo cf5c162d672e4e58b4dde5d797...
This document serves as a comprehensive step-by-step guide on how to effectively use PyCharm for remote debugging of the Windows Subsystem for Linux (WSL) on a local Windows machine. It meticulously outlines several critical steps in the process, starting with the crucial task of enabling permissions, followed by the installation and configuration of WSL.
The guide then proceeds to explain how to set up the SSH service within the WSL environment, an integral part of the process. Alongside this, it also provides detailed instructions on how to modify the inbound rules of the Windows firewall to facilitate the process, ensuring that there are no connectivity issues that could potentially hinder the debugging process.
The document further emphasizes on the importance of checking the connection between the Windows and WSL environments, providing instructions on how to ensure that the connection is optimal and ready for remote debugging.
It also offers an in-depth guide on how to configure the WSL interpreter and files within the PyCharm environment. This is essential for ensuring that the debugging process is set up correctly and that the program can be run effectively within the WSL terminal.
Additionally, the document provides guidance on how to set up breakpoints for debugging, a fundamental aspect of the debugging process which allows the developer to stop the execution of their code at certain points and inspect their program at those stages.
Finally, the document concludes by providing a link to a reference blog. This blog offers additional information and guidance on configuring the remote Python interpreter in PyCharm, providing the reader with a well-rounded understanding of the process.
IEEE Aerospace and Electronic Systems Society as a Graduate Student Member
IEEE Aerospace and Electronic Systems Society as a Graduate Student Member
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
Slides for the 4th Presentation on LLM Fine-Tuning with QLoRA Presented by Anant, featuring DataStax Astra
cnn.pptx Convolutional neural network used for image classication
Convolutional Neural Network used for image classification
KuberTENes Birthday Bash Guadalajara - K8sGPT first impressions
K8sGPT is a tool that analyzes and diagnoses Kubernetes clusters. This presentation was used to share the requirements and dependencies to deploy K8sGPT in a local environment.
Null Bangalore | Pentesters Approach to AWS IAM
#Abstract:
- Learn more about the real-world methods for auditing AWS IAM (Identity and Access Management) as a pentester. So let us proceed with a brief discussion of IAM as well as some typical misconfigurations and their potential exploits in order to reinforce the understanding of IAM security best practices.
- Gain actionable insights into AWS IAM policies and roles, using hands on approach.
#Prerequisites:
- Basic understanding of AWS services and architecture
- Familiarity with cloud security concepts
- Experience using the AWS Management Console or AWS CLI.
- For hands on lab create account on [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
# Scenario Covered:
- Basics of IAM in AWS
- Implementing IAM Policies with Least Privilege to Manage S3 Bucket
- Objective: Create an S3 bucket with least privilege IAM policy and validate access.
- Steps:
- Create S3 bucket.
- Attach least privilege policy to IAM user.
- Validate access.
- Exploiting IAM PassRole Misconfiguration
-Allows a user to pass a specific IAM role to an AWS service (ec2), typically used for service access delegation. Then exploit PassRole Misconfiguration granting unauthorized access to sensitive resources.
- Objective: Demonstrate how a PassRole misconfiguration can grant unauthorized access.
- Steps:
- Allow user to pass IAM role to EC2.
- Exploit misconfiguration for unauthorized access.
- Access sensitive resources.
- Exploiting IAM AssumeRole Misconfiguration with Overly Permissive Role
- An overly permissive IAM role configuration can lead to privilege escalation by creating a role with administrative privileges and allow a user to assume this role.
- Objective: Show how overly permissive IAM roles can lead to privilege escalation.
- Steps:
- Create role with administrative privileges.
- Allow user to assume the role.
- Perform administrative actions.
- Differentiation between PassRole vs AssumeRole
Try at [killercoda.com](https://killercoda.com/cloudsecurity-scenario/)
BRAIN TUMOR DETECTION for seminar ppt.pdf
BRAIN TUMOR DETECTION
AND CLASSIFICATION USING
ARTIFICIAL INTELLIGENCE
Data Driven Maintenance | UReason Webinar
Discover the latest insights on Data Driven Maintenance with our comprehensive webinar presentation. Learn about traditional maintenance challenges, the right approach to utilizing data, and the benefits of adopting a Data Driven Maintenance strategy. Explore real-world examples, industry best practices, and innovative solutions like FMECA and the D3M model. This presentation, led by expert Jules Oudmans, is essential for asset owners looking to optimize their maintenance processes and leverage digital technologies for improved efficiency and performance. Download now to stay ahead in the evolving maintenance landscape.
Computational Engineering IITH Presentation
This Presentation will give you a brief idea about what Computational Engineering at IIT Hyderabad has to offer.
Mechanical Engineering on AAI Summer Training Report-003.pdf
Mechanical Engineering PROJECT REPORT ON SUMMER VOCATIONAL TRAINING
AT MBB AIRPORT
Kürzlich hochgeladen (20)
International Conference on NLP, Artificial Intelligence, Machine Learning an...
International Conference on NLP, Artificial Intelligence, Machine Learning an...
artificial intelligence and data science contents.pptx
artificial intelligence and data science contents.pptx
Use PyCharm for remote debugging of WSL on a Windo cf5c162d672e4e58b4dde5d797...
Use PyCharm for remote debugging of WSL on a Windo cf5c162d672e4e58b4dde5d797...
Generative AI leverages algorithms to create various forms of content
Generative AI leverages algorithms to create various forms of content
IEEE Aerospace and Electronic Systems Society as a Graduate Student Member
IEEE Aerospace and Electronic Systems Society as a Graduate Student Member
Introduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptx
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
cnn.pptx Convolutional neural network used for image classication
cnn.pptx Convolutional neural network used for image classication
KuberTENes Birthday Bash Guadalajara - K8sGPT first impressions
KuberTENes Birthday Bash Guadalajara - K8sGPT first impressions
Mechanical Engineering on AAI Summer Training Report-003.pdf
Mechanical Engineering on AAI Summer Training Report-003.pdf
What is the right unit in unit testing (UpdateConf 2022)
- 1. …and why is it (often) not a single 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
- 4. Why is this important?
- 5. Because we like… …code that can be changed by any developer in the team without fear and with confidence
- 6. Test Driven Development in reality 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
- 7. Pros and cons of different levels of testing Exploratory Testing Browser Testing HTTP/API Tests Component/Integration Tests “Unit” Tests Scope, Execution Time and flakiness Simplicity & Ease of debugging
- 13. Smells & heuristics to find the right scope
- 14. Designed for reusability? Then tested separately
- 15. Is it an implementation detail? Then don’t test it directly
- 16. Is the test really testing the real surface area?
- 17. Does refactoring require rewriting the tests?
- 18. Things in adjacent folders usually mean they are separate
- 19. Returning mocks from mocks is often a sign of a scope issue
- 20. Tips to improve testability
- 22. It’s fine to include the database in tests
- 23. It’s fine to test smaller when it adds value
- 24. Don't bother arguing about “unit” vs “integration”
- 26. Apply DRY within those boundaries
- 27. Mock the dependencies outside of the scope
- 28. A less trivial example
- 29. Command Handlers Commands Domain Model Event Store Events App Read Data RavenDB Projectors Events HTTP API Projections Events
- 30. Test Fixture In-Memory Event Store Read Data RavenDB Projectors Events HTTP API Projections Unit Test HTTP request Test Data Sources: https://tinyurl.com/4sukm55n
- 31. Ask a great questions …and win a Jetbrains 1-year license …ask at fluentassertions.slack.com …ping me at @ddoomen …email me at dennis.doomen@avivasolutions.nl