This is not a deck about how or why to practice TDD. Based upon research conducted, I outline the most common objections to TDD and describe how to refute (or more properly rebut), avoid or mitigate each of them. The coverage acknowledges that there are risks inherent to all techniques and does not promote the idea that TDD is some kind of silver bullet.
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Leadership Without Management: Scaling Organizations by Scaling Engineersbcantrill
My talk at Surge 2013. Video is at http://www.youtube.com/watch?v=bGkVM1B5NuI Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.
It was back in ‘97 when Brian Foote and I first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud. A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Still, this approach endures and thrives. Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?
This keynote will examine the paradoxes that underlie Big Balls of Mud, what causes them, and why they are so prominent. What Agile Practices help us avoid or cope with mud? Does Agile practices such as TDD really help minimize mud? What are we doing RIGHT? What Agile Practices contribute to the problem? Encourage mud? Is Mud really the best that Agile can do? Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Leadership Without Management: Scaling Organizations by Scaling Engineersbcantrill
My talk at Surge 2013. Video is at http://www.youtube.com/watch?v=bGkVM1B5NuI Caution: Should not be consumed by stack-ranking six-sigma black belts with fragile constitutions.
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Researchers in model-driven development (MDD) should be intimately familiar with how MDD is used in industry. If they are not, there is a danger that new methods and tools are developed without proper consideration for the way that MDD developers actually work and think. A thorough understanding of current MDD industrial practice can inform research problems and ensure that research solutions are actually adopted.
This talk will describe results from a year long study, which applied methods from social science to understand how MDD is actually used in industry. Based on a survey of over 400 MDD practitioners, in-depth interviews with 22 industry professionals from 17 different companies, and a small number of on-site observational studies, the talk will discuss the current state-of-practice in industrial use of MDD, and will offer some insights on current research gaps.
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Mob Programming - Whole Team CollaborationNick Goede
Learn about a new development practice that is gaining popularity. Built off of the values of lean and extreme programming, mob programming optimizes for the flow of work.
How to get what you really want from Testing' with Michael BoltonTEST Huddle
EuroSTAR Conferences, with the support of ISA Software Skillnet, Irish Software Innovation Network and SoftTest, were delighted to bring you a half-day software testing masterclass with Michael Bolton
In this session, Michael Bolton (who has extensive experience as a tester, as a programmer, and as a project manager) explained the role of skilled software testers, and why you might not want to think of testing as "quality assurance".
He present ideas about the relationship between management and testers, and about the service that testers really provide: making quality assurance possible by lighting the way of the project. For those of you who who attended this event, we really hope it was of use to you in your testing careers.
www.eurostarconferences.com
Agile Architecture and Modeling - Where are we TodayGary Pedretti
Ideals, Misinterpretations, Backlash, a New Hope - A talk on where we've been and where we're going with agile application architecture. As presented at Toronto Agile and Software 2014 on 11/10/2014.
Tried putting things in the deck that I learnt about Extreme programming in XP Conference held in Bangalore. I have tried to keep it at very high level added with light moments, so that it doesn't getting boring and makes sense for most of us
Do you already know what big ball of mud means?
And code smell?, Is your nose prepared to detect them?
Can you affirm that you are commited with the mantainability?
Do you have architectural sensibility to avoid these kind of situations? Or you are comfortable with the inertia of the day-to-day task of patching the holes. (it doesn't matter if it works..)
While much attention has been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture is seldom discussed.
This talk is intended to identify and summarize the causes that lead to misusing our time on complex maintenance, and give tips and best practices to avoid the big ball of mud and to achieve the best quality products.
Researchers in model-driven development (MDD) should be intimately familiar with how MDD is used in industry. If they are not, there is a danger that new methods and tools are developed without proper consideration for the way that MDD developers actually work and think. A thorough understanding of current MDD industrial practice can inform research problems and ensure that research solutions are actually adopted.
This talk will describe results from a year long study, which applied methods from social science to understand how MDD is actually used in industry. Based on a survey of over 400 MDD practitioners, in-depth interviews with 22 industry professionals from 17 different companies, and a small number of on-site observational studies, the talk will discuss the current state-of-practice in industrial use of MDD, and will offer some insights on current research gaps.
The Technical Debt Trap - Michael "Doc" NortonLeanDog
Technical Debt has become a catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code.
These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions.
What is technical debt?
What is not technical debt?
Why should we care?
What is the cost of misunderstanding?
What do we do about it?
Mob Programming - Whole Team CollaborationNick Goede
Learn about a new development practice that is gaining popularity. Built off of the values of lean and extreme programming, mob programming optimizes for the flow of work.
How to get what you really want from Testing' with Michael BoltonTEST Huddle
EuroSTAR Conferences, with the support of ISA Software Skillnet, Irish Software Innovation Network and SoftTest, were delighted to bring you a half-day software testing masterclass with Michael Bolton
In this session, Michael Bolton (who has extensive experience as a tester, as a programmer, and as a project manager) explained the role of skilled software testers, and why you might not want to think of testing as "quality assurance".
He present ideas about the relationship between management and testers, and about the service that testers really provide: making quality assurance possible by lighting the way of the project. For those of you who who attended this event, we really hope it was of use to you in your testing careers.
www.eurostarconferences.com
Agile Architecture and Modeling - Where are we TodayGary Pedretti
Ideals, Misinterpretations, Backlash, a New Hope - A talk on where we've been and where we're going with agile application architecture. As presented at Toronto Agile and Software 2014 on 11/10/2014.
Tried putting things in the deck that I learnt about Extreme programming in XP Conference held in Bangalore. I have tried to keep it at very high level added with light moments, so that it doesn't getting boring and makes sense for most of us
xUnit and TDD: Why and How in Enterprise Software, August 2012Justin Gordon
“A comprehensive suite of JUnit tests is one of the most import aspects of a software project because it reduces bugs, facilitates adding new developers, and enables refactoring and performance tuning with confidence. Test-driven development (TDD) is the best way to build a suite of tests. And the Dependent Object Framework is the best way to test against database objects.” This presentation covers the benefits of TDD along with practical advice on how to implement TDD in complex projects.
Why software will never be the same... Discuss why agile and lean development methodologies alone are not enough to compete in today's software startup market. Explore real-time prototyping and minimal viable experiments that can accelerate learning down to hours, not sprints.
Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it.
For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good.
The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value.
Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff.
While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges.
This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges.
Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)
Software contracts - Global Enterprise Agile 2023.pdfSeb Rose
The rise of micro-service architectures offers the promise of a more agile software development process.
Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organizations. But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith?
Contract testing offers an excellent solution.
Participants will be able to:
- Explain why contract testing is critically important
- Describe how to incorporate contract testing in your development practices
- Show their team where they can get an introduction to the open source tool, Pact.
Micro-service delivery - without the pitfallsSeb Rose
The days of delivering a monolithic desktop application once a year on physical media are long gone. Today we expect continuous (or at least frequent) delivery of upgrades and security patches with zero downtime. To support this, more and more companies are moving to a distributed, cloud-based architecture of collaborating micro-services. But managing and testing an evolving of a micro-service ecosystem is not without it’s challenges.
In this session we’ll examine what can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls. You’ll leave with an understanding of the techniques and tooling necessary to reap the benefits of increased flexibility and velocity without creating additional risk or deployment nightmares.
New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You will be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others. A new kid on the block is DevSecOps. What does that mean? Why is it important? How will it affect agile software teams? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome? In this session I’ll explore the origins of DevSecOps before going on to demonstrate how there’s often a distance between the label and the intent of DevSecOps. Finally I’ll discuss the impact that DevSecOps can have on our agile teams and organisations based on my perspective gathered over a 40 year career in software.
Microservices architecture has become the new norm in software development. CI/CD delivery had made releasing updates so frequent it’s almost a daily thing. Modern Software delivery allows no downtime and creates new challenges.
In this webinar, Seb Rose, Continuous Improvement Lead at SmartBear, and Alon Eizenman, CTO & Co-Founder at SeaLights will examine what can go wrong when organizations jump headfirst into microservices architectures without understanding the potential pitfalls.
Join this webinar to learn:
Techniques and tooling necessary to reap the benefits of increased flexibility and velocity without creating additional risk or deployment nightmares
How to gain visibility to ensure your coverage in each microservice
How to set quality gates without delaying release to production
Example mapping - slice any story into testable examples - SoCraTes 2022.pdfSeb Rose
Example mapping is a simple but powerful technique for structuring the conversation you need to have before a user story goes into development. If you are struggling with user stories that are too big, or hard to test, or you're finding that the team are not all on the same page about the scope of a user story, Example Mapping could be just what you need. Using a regular pack of coloured index cards, we'll work in groups to practice breaking down the details of a user story, capturing the business rules, examples of those rules, and any questions or assumptions that emerge. Example mapping is a great input to a BDD or ATDD process, but that's not essential. You'll still get a lot out of this conversation technique even if you don't turn the examples into automated tests.
Software testing - learning to walk again (expoQA22)Seb Rose
Software testing seems to advance at an ever increasing pace. However, lurking under the surface of relentless progress, Seb Rose believes there is a rich strata of continuity. In this session he will explore these foundational aspects of our trade - informally and illustrated by some pretty pictures.
The first article Seb wrote for a software journal was in 2003 (https://accu.org/index.php/articles/363) where he drew an awkward analogy between software projects and building a shed. Over the years, he has found that he has a penchant for analogies and this session will continue in that vein. Don’t worry, though, he’s not going to bore you with pictures of building sites or aphorisms from lean manufacturing.
Instead, he’ll take you on a gentle walk on some mountainous paths in the south of France. There’ll be red wine and automated testing; oak forests and scope creep; deep river gorges and CI pipelines. He’ll ask you to walk with him and take a close look at the concepts that underpin our trade.
“We must learn to walk before we can run” is an age-old adage. We all learned to walk decades ago. Many of us learnt how to test software shortly thereafter. However, just as running is not simply walking faster, neither is better software testing simply working with the latest shiny tools. By slowing down, observing our behaviour, considering alternatives, and deliberately practicing different approaches we can re-learn how to develop software. Or confirm that how we’re doing it now is just fine.
As Jon Jagger reminds us in the FAQ of the wonderful Cyber-Dojo: “Stop trying to go faster; start trying to go slower. Don’t think about finishing; think about improving. Think about practicing.”
From this keynote, you’ll enjoy a gentle walk on some mountainous paths in the south of France, some red wine with unit testing and above all understand how to walk before running.
DevSecOps - Unicom Agile and DevOps Expo (Adaptive Challenges) 2021Seb Rose
New software development approaches continue to be promoted. You may be aware of waterfall, RUP, 4GLs, 3-tier client server – all still alive and kicking in some domains. You will be familiar with some (or all) of Agile, Kanban, DevOps, SAFe, No Code/Low Code and many others.
A new kid on the block is DevSecOps. What does that mean? Where did it come from? Why is it important? If we adopted the tenets of DevSecOps without calling it DevSecOps would it “smell just as sweet”? What would it “smell” like if we spun up a DevSecOps team, without understanding the fundamental challenges that DevSecOps was intended to overcome?
In this session I’ll explore the origins of DevSecOps before going on to demonstrate the distance between the label and the intent of DevSecOps. Finally I’ll try to generalise the journey from “good idea” to “empty slogan” that seems to underpin many of the hyped transformations that I’ve lived through during my 40 year career in software.
A brief history of requirements - Unicom 2022Seb Rose
Was there a time before requirements? Can the product be created before the requirements? Is a product ever “finished”? These are just some of the questions considered in this session. It begins by reviewing the great requirement formalisms of yester-year, before delving into the secrets which still lie at the heart of agile product development, from user stories to living documentation, via confetti parties and Behaviour Driven Development (BDD)
* BDUF – Big Design Up Front
** JIT – Just In Time
Example mapping (with builds) - ProductWorld 2022Seb Rose
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?
Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.
No code, low code, machine code QA ATL 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
No code, low code, machine code QA ATL 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
No code, low code, machine code - Unicom 2021Seb Rose
Everything looks solvable if you ignore most of the complications. Many things look impossible if you’re stuck in the weeds. The current fashion for low/no code solutions heralds the cyclical return to looking for solutions that require softer skillsets. When is this appropriate and when is it a recipe for disaster?
BDD: from soup to nuts - The Future of Work Scotland 2021Seb Rose
Behaviour Driven Development (BDD) is an agile approach to delivering software that has been around for well over a decade. It was created to help developers care about quality, morphed into a collaboration approach, and found widespread mis-adoption as a test automation technique.
In this session Seb will explain how BDD is intended to work, what value it delivers when done well, and why much BDD in the workplace falls short.
Learning Objectives:
What can our attendees expect to take away from the session?
● enumerate the three core practices of BDD
● explain the difference between BDD and test automation
● argue that collaboration and learning are at the heart of successful software development
Contrasting test automation and BDD - 2020Seb Rose
Test automation and BDD are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.
In this session we’ll explore what test automation and BDD are - and how they separately contribute to successful inter-disciplinary agile delivery. We'll also spend some time describing how they're different, and look at several typical examples of what can go wrong when BDD and test automation get confused.
Are BDD and test automation the same thing? Automation Guild 2021Seb Rose
Test automation and behaviour-driven development (BDD) are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.
In this session we’ll explore what test automation and BDD are – and how they separately contribute to successful inter-disciplinary agile delivery. We’ll also spend some time describing how they’re different, and look at several typical examples of what can go wrong when BDD and test automation get confused.
"Our BDDs are broken!" Lean Agile Exchange 2020Seb Rose
Is the goal of your QA team to increase the number of automated tests? Are managers looking for tools that allow test-automation without the need for development skills? Are you using Given/When/Then phrasing to write automation tests?
In this session we’ll briefly define what BDD is, spend a bit longer describing what it isn’t, and look at several typical examples of what can go wrong if you use Cucumber when you’re not following a BDD approach.
User stories: from good intentions to bad advice - Agile Scotland 2019Seb Rose
These are the slides I wanted to use at Agile Scotland 2019. Unfortunately, my laptop refused to play ball and I ended up using an older version that was already on SlideShare.
User stories: from good intentions to bad advice - Lean Agile Scotland 2019Seb Rose
User stories are one of the most visible artefacts of most agile methods and, as such, have generated large quantities of expert advice. In my experience, much of that advice is open to misinterpretation.
In this session, we'll explore several classic pieces of advice, to see how misunderstandings can cause problems, despite the best intentions. The examples we'll look at are:
- an acronym: INVEST, created by Bill Wake
- a technique: relative estimation using story points, created by Ron Jeffries or Joseph Pelrine
- a template: Connextra (As-A/I-Want/So-That), created by Rachel Davies
Expert advice taken in good faith, that leads to bad outcomes, can cause us to become distrustful. It's time to reiterate that there is no magic formula, no silver bullet. At best, experts can lend you a framework within which to think, but their advice will never make thinking unnecessary.
Software contracts or: how I learned to stop worrying and love releasing. Agi...Seb Rose
The test automation pyramid suggests that we should favour unit and integration tests over end-to-end tests, which leads developers to use test doubles (fakes, stubs, mocks etc.). The risk is that the developer's test double does not behave in exactly the same way as the actual component that it is replacing. When this happens, the tests all pass in your build pipeline, but you get failures when it's released into an integration (or production) environment.
Contract testing is a technique that can give you confidence that your test doubles are accurately simulating the dependencies that they replace. This is not a new technique, but the extra investment in creating and maintaining (yet another) suite of tests has restricted its uptake. Instead, organizations mitigate the risks by investing in more and more integration environments and end-to-end tests. This was always expensive, but with the adoption of micro-service architectures across the industry, the cost and complexity has escalated to a point where this approach is no longer sustainable.
There is now an urgent need for organizations to revisit contract testing, with a specific focus on consumer driven contracts for micro-services. This need led to the creation of the Pact open source tool for HTTP based micro-services. The Pact project has created a multi-platform suite of tools that dramatically simplifies the adoption of contract testing.
In this session, you'll learn why contract testing is critically important, look at how you can incorporate contract testing in your development practices, and get an introduction to Pact.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
2. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
2
Innovation for a smarter planet
3. IBM Software Group | Rational software
Refutations. Really?
re·fute
/rɪˈfyut Show Spelled
/
verb (used with object), re·fut·ed, re·fut·ing.
1. to prove to be false or erroneous, as an opinion or
charge.
2. to prove (a person) to be in error.
3
Innovation for a smarter planet
4. IBM Software Group | Rational software
TDD – in one slide
Test First predates XP and Agile
TDD has been around for a while
One of XP‟s core practices
Widely referenced
Still quite controversial
I am not going to describe TDD in any detail
Red/Green/Refactor (and variants)
„T‟ for Test has unfortunate connotations
First „D‟ definitely stands for Driven
Second „D‟ may stand for Development or Design
4
Innovation for a smarter planet
6. IBM Software Group | Rational software
Survey
Simple survey ran for 3 months
Jan – Mar 2012
260 unique respondents
896 objections
“What reasons are there not to practice TDD”
“The question wreaks of elitism - it should instead be „what reasons are
there to practice TDD‟”.
Free text made for a wide range of responses
Harder to analyse
Split into 18 types, grouped into 5 categories
6
Innovation for a smarter planet
7. IBM Software Group | Rational software
Results
Education
Time
Benefits
Project
Cultural
7
Innovation for a smarter planet
8. IBM Software Group | Rational software
Breakdown
Education (223)
Lack of Practice, Lack of Investment
Project (194)
Domain, Legacy, Environment, Tooling
Cultural (179)
Management, Team, Fanaticism, Demarcation, Egotism
Time (174)
Slowness of development, maintenance and execution
Benefits (120)
Lack of Proof & Experience, Alternatives
8
Innovation for a smarter planet
9. IBM Software Group | Rational software
Interconnectedness of all things
Classification is subjective
Many responses could be categorised several ways
Respondents had different points of view
Their own objections
Objections they had heard others express
Further analysis required
Follow-up survey(s)
9
Innovation for a smarter planet
10. IBM Software Group | Rational software
10
Innovation for a smarter planet
11. IBM Software Group | Rational software
Software Crisis!
The required techniques of effective reasoning
are pretty formal, but as long as programming is
done by people that don't master them, the
software crisis will remain with us and will be
considered an incurable disease. And you know
what incurable diseases do: they invite the
quacks and charlatans in, who in this case take
the form of Software Engineering gurus.
- Dijkstra (ACM Turing Award Lecture 1972)
11
Innovation for a smarter planet
12. IBM Software Group | Rational software
Fanaticism and Fluff
The steps of FDD are simple:
1. Take a tiny piece of fluff from the plate and put it on your
head, holding your head quite still to ensure that the fluff
does not fall off your hair.
2. Write a line of code.
3. Say, “I am the Fluff Lord, within the Dominion Of The
Fluffists.”
4. Repeat.
That’s it.
Seriously, that’s all there is to it.
12
Innovation for a smarter planet
13. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
Wrap up
13
Innovation for a smarter planet
14. IBM Software Group | Rational software
Hard to learn
“TDD is hard.”
Yes, it is
Any technique is hard to master
Fundamental changes are hard to adopt
10,000 hours of practice
Did you stop trying to ride a bicycle when you fell off?
14
Innovation for a smarter planet
15. IBM Software Group | Rational software
Where to start
“Sheer lack of knowledge on how to approach it appropriately.
There are too many bowling examples and not enough
practicality.”
How do you usually learn something new?
Unit Testing skills are foundational
Coding Dojo to practice TDD
http://cyber-dojo.com
Better used as a group, but still useful solo
15
Innovation for a smarter planet
16. IBM Software Group | Rational software
Tests before code
“The compiler complains if I write tests before the code”
First step to get to green is to make the test compile
Only then can you move on to make the test pass
16
Innovation for a smarter planet
17. IBM Software Group | Rational software
Tests will be buggy
“Your test code is just your production code, written from the
other end (i.e. just as complex and likely to have bugs)”
No process is infallible
“To err is human …”
Safety in numbers
Pair programming
Peer review
17
Innovation for a smarter planet
18. IBM Software Group | Rational software
Unfamiliar architectural style
“How will we ever know what‟s going on if we can't see all of
the code at once?”
TDD tends to lead to small, concise implementations
Low coupling
High cohesion
“Proliferation” of interfaces
Literate-ish programming
18
Innovation for a smarter planet
19. IBM Software Group | Rational software
No design improvement
“My observations of code from TDD-based projects show no
significant improvement in architecture, security, code
style, testability, etc. over other projects built with testing in
mind.”
TDD ensures testability
Tendency for smaller decoupled composition
Other design concerns (e.g. security, performance etc.) not
addressed by TDD
19
Innovation for a smarter planet
20. IBM Software Group | Rational software
Learning several things at once
“In a new technology, it's too difficult to learn how to TDD as
well as how to master that technology.“
Even if you are experienced with TDD, it changes your
perspective on the new technology
Idioms
Tooling
Kent Beck suggests reimplementing xUnit in the new
language
20
Innovation for a smarter planet
21. IBM Software Group | Rational software
Discipline
“TDD is a discipline and a work habit. It's very difficult to
establish the habit.”
Habits are hard to form, but also hard to break.
Nothing works better than positive feedback
There are many self-help guides available
Switch – Chip & Dan Heath
Drive – Dan Pink
21
Innovation for a smarter planet
22. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
Wrap up
22
Innovation for a smarter planet
23. IBM Software Group | Rational software
Too simple
"This code is too simple to need a test“
Then the tests will be simple too
What‟s simple to you may be opaque to others
As the code evolves, tests can help keep it simple
23
Innovation for a smarter planet
24. IBM Software Group | Rational software
Just a spike
“Because you're prototyping an idea and it's much faster to
spike without tests. If you do end up using the code then you
can write tests and refactor.”
Use the right tool – TDD is not mandatory
Discipline to ensure spike does not mutate
“Write one to throw away”
TDD the spike anyway!
24
Innovation for a smarter planet
25. IBM Software Group | Rational software
Not useful for all aspects of design
“I don't think that deriving a design by writing tests is a useful
practice. Tests by themselves cannot cover many aspects of
a design (designing for concurrency and performance in
particular by writing tests is something that I've never seen
anyone do).”
TDD is not the only tool in the toolbox
Probably wrong tool for performance testing
Can be applied to concurrency testing (but not recommended)
25
Innovation for a smarter planet
26. IBM Software Group | Rational software
Not useful for functional/declarative programming
“Because it is largely adequate in imperative programming
and not when you go functional and declarative - when code
reads like specification.”
Orthogonal.
Absence of side effects makes testing MORE effective.
Discuss!
26
Innovation for a smarter planet
27. IBM Software Group | Rational software
Legacy code
“Difficulty starting with legacy code. A simple change done
through TDD can take orders of magnitude longer due to a
need to redesign toward testability. ”
Working Effectively With Legacy Code – Feathers
Small, conservative steps, eventually tame fear and doubt
Consider less intrusive approaches initially
e.g. TextTest – texttest.org
27
Innovation for a smarter planet
28. IBM Software Group | Rational software
Insufficient tooling
“There is no unit-test framework for the language I'm
using, and I don't have time/inclination to develop one
myself.”
There probably is.
You might not need one
“TDD in C” – Olve Maudal
28
Innovation for a smarter planet
29. IBM Software Group | Rational software
GUI
“I do a lot of UI code and don't really know how to properly do
that with TDD.”
“Subcutaneous” testing
Presenter First pattern
Based on MVC/MVP patterns
Very shallow view, with no business logic
Stateless presenter orchestrates interaction between view and model
29
Innovation for a smarter planet
30. IBM Software Group | Rational software
Excessive coupling to data
“A test expresses a unit of change as data that fits the needed
computation. Creating that data is harder than writing the
program that accomplishes the change.”
Unit tests preferably utilise „small‟ amounts of data
For domains where this is not possible
You will need large amounts of data irrespective of test approach
Bootstrap process with constructed data
Continue with captured data
30
Innovation for a smarter planet
31. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
Wrap up
31
Innovation for a smarter planet
32. IBM Software Group | Rational software
Management antipathy
“Management want results NOW; very much willing to clean
up small oversights later. 'Close is good enough' attitude.”
Management are generally result focused
Previous bad experiences affect appetite for change
Both ways!
Start small
Need to demonstrate benefit to „bottom line‟
32
Innovation for a smarter planet
33. IBM Software Group | Rational software
Team resistance
“Teammates are not prepared. They do not have enough
knowledge or experience in unit testing.”
“No one tells me how to program!”
Changing behaviours is hard
“Fearless Change” has many patterns for introducing change
33
Innovation for a smarter planet
34. IBM Software Group | Rational software
I never make mistakes
“I already know what the code needs to do and it's low risk. I
don't need a test for it.”
“My first design idea is always perfectly good.”
“My code always works the first time.”
Do people really believe this?
Even if they do, is everyone that ever touches the code going
to be so talented?
34
Innovation for a smarter planet
35. IBM Software Group | Rational software
Testing is for testers
“We don't need TDD, we've got a QA department. They'll find
the bugs for us.”
TDD is not just about testing
Drives design
Refactoring/regression safety net
Write tests to explore EVERY defect you find
Living documentation
Helps future developers understand intended behaviours
35
Innovation for a smarter planet
36. IBM Software Group | Rational software
All TDD-ers are fanatics
“It has become a cult. Its advocates have made it antithetical
to „Individuals and interactions over processes and tools‟. It is
evangelized through coercion and browbeating --
necessarily, as it isn't compelling on it's own.”
“Someone needs to tell unclebob that he might be right, but
he's part of the problem - to non-modern coders (which felt
like the majority last time I looked) he comes across like a
raving loony.”
36
Innovation for a smarter planet
37. IBM Software Group | Rational software
Fluff (continued)
If at any time you even THINK about writing a line of code
before putting fluff on your head, then you‟ve to delete all your
code, shake all the fluff from your head onto the plate and start
all over again.
I have been practicing FDD for 12 years now; sometimes in the
office, I have so much fluff on my head that my boss thinks I‟m
a hay-stack, only made of fluff. A sort-of fluff-stack, if you will.
But one thing is beyond doubt: the code I write, when I‟m in this
fluff-zone, is the most high-quality code that anyone has ever
seen.
37
Innovation for a smarter planet
38. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
Wrap up
38
Innovation for a smarter planet
39. IBM Software Group | Rational software
More code to write
“Takes too much time to write test.”
How will your code get tested?
Test team?
Customers & Stack Trace Driven Development?
How much time will be spent figuring out how to make
changes later?
What proportion of your time do you actually spend coding?
39
Innovation for a smarter planet
40. IBM Software Group | Rational software
More code to maintain
“If I change something it will break a whole bunch of tests that
I will have to fix and it will be more work for me in the end
than just verifying my changes manually.”
It is USEFUL to know when behaviour changes
Foundational Unit Testing skills reduce brittleness
next 6 slides
40
Innovation for a smarter planet
41. IBM Software Group | Rational software
Testability
Testability needs to be designed in
TDD ensures code is testable
Code with hidden dependencies is hard to test
Dependency Injection/Inversion
Pass dependencies into code under test
Write factories that permit injection of test doubles
Interfaces should be cohesive
Wide interfaces encourage unnecessary coupling
Avoid globals, singletons etc.
Retro-fitting unit tests is hard
Take small steps
Introduce a „seam‟ – c.f. Working Effectively with Legacy Code
41
Innovation for a smarter planet
42. IBM Software Group | Rational software
Necessity
Test observable behaviour
Don‟t modify encapsulation to aid testing
If a behaviour isn‟t observable through the public interface what is it for?
Don‟t slavishly write one test per method
Test behaviours
Some methods may not need any dedicated tests
Methods that implement useful behaviours may need many tests
Choose test variants carefully
Edge conditions
Invalid inputs
Multiple invocations
Error signalling
42
Innovation for a smarter planet
43. IBM Software Group | Rational software
Granularity
Test a SINGLE observable behaviour
It is tempting to combine related behaviours in a single test – DON‟T
… even if EXACTLY the same steps are needed
public void shouldSortTwoStringsAndReportCorrectSize() {
SortedSet<String> animals = new TreeSet<String>();
animals.add(“Zebra”);
animals.add(“Anteater”);
assertEquals(2, animals.size());
assertEquals(“Anteater”, animals.first());
assertEquals(“Zebra”, animals.last());
}
43
Innovation for a smarter planet
44. IBM Software Group | Rational software
Understandability
Name tests to describe the behaviour under test
Describe nature of the test
Is it checking that preconditions are enforced?
Is a dependency going to signal an error?
Long names are fine – you only type them once
Be precise
shouldReturnCorrectValue is not a good name for a test
shouldReturnCorrectSumOfTwoIntegersWithoutOverflow
should_return_correct_sum_of_two_integers_without_overflow
When a test fails you want to know WHAT WENT WRONG
You don‟t want to reverse engineer the test
You don‟t want to run smaller tests to isolate the failure
44
Innovation for a smarter planet
45. IBM Software Group | Rational software
Maintainability
Unit Tests should be written to same quality as Production code
Tests will be maintained and read just as often as production code
Code is communication to other developers not just a compiler
Organise tests into cohesive suites
Refactor tests to avoid duplication
Use suites to perform common set up/tear down operations
Extract common code into methods
Extract common functionality into classes
Remove redundant tests
45
Innovation for a smarter planet
46. IBM Software Group | Rational software
Reiteration: 5 -ities
Testability
Necessity
Granularity
Understandability
Maintainability
MUNGT ?
TeNGUM?
46
Innovation for a smarter planet
47. IBM Software Group | Rational software
Mock-based tests rot
“Unit-test mock/stub assumptions rots”
Use collaboration and contract tests – J.B. Rainsberger
Collaboration tests make assumptions about the contract; contract tests
try to justify those assumptions
A stub in a collaboration test must correspond to an expected result in a
contract test
An expectation in a collaboration test must correspond to an action in a
contract test
47
Innovation for a smarter planet
48. IBM Software Group | Rational software
That library is third party
“API layers above and below you don't provide adequate
mocks. Testing against the „real thing‟ is hard/impossible.”
“Don't mock types you don't own” – Joe Walnes
Write adapters that provide a domain specific API
Write acceptance tests that verify the library‟s behaviour
Run whenever adopting a new version
48
Innovation for a smarter planet
49. IBM Software Group | Rational software
Slow execution
“Running the tests takes too long.”
For TDD to work tests need to (build and) execute in seconds
Some environments need careful configuration
C/C++
Rails
Are they really Unit Tests? (See next slide)
49
Innovation for a smarter planet
50. IBM Software Group | Rational software
A test is not a unit test if:
It talks to the database
It communicates across the network
It touches the file system
It can‟t run at the same time as other unit tests
You have to do special things to your environment (such as
editing config files) to run it
(Michael Feathers‟ blog, 2005)
50
Innovation for a smarter planet
51. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
Wrap up
51
Innovation for a smarter planet
52. IBM Software Group | Rational software
Absence of research
“No scientific proof of it actually having any benefit (compared
to just code reviews, pair programming or etc.) for the same
amount of time”
“It's not practical for the kind of work I do. By which I mean, it
cannot be conclusively shown to provide tangible benefits that
outweigh the perceived costs.”
“In an industry where todays must have offering is tomorrows
dustbin liner, it's often prudent to wait before trying the latest
snake oil!”
52
Innovation for a smarter planet
53. IBM Software Group | Rational software
Absence of research (cont.)
“We found that test-first students on average wrote more tests
and, in turn, students who wrote more tests tended to be
more productive. We also observed that the minimum quality
increased linearly with the number of programmer
tests, independent of the development strategy employed.”
On the Effectiveness of Test-first Approach to Programming
Proceedings of the IEEE Transactions on Software Engineering 2005
Lots of other papers are referenced from:
http://bradapp.blogspot.co.uk/2009/08/studies-on-effectiveness-of-tdd.html
53
Innovation for a smarter planet
54. IBM Software Group | Rational software
Our process is good enough already
“My team doesn't practice it. It is difficult to change existing
practices if they seem to work reasonably well.”
“I've personally been a part of four 'large' software projects
where active pursuit of a test suite was in play. None of the
four projects ever launched into production. The people I
worked with were smart and highly ambitious, yet they (we)
failed to launch.
“I've personally been a part of dozens of software projects
where active pursuit of a test suite was NOT in play. Most
every one of those projects launched into production in a
timely manner.”
54
Innovation for a smarter planet
55. IBM Software Group | Rational software
Test after
“It's easier to write the code first and the test after.”
“Writing tests after code is just as good.”
“Writing tests before code doesn't make sense.”
Testability
Rework needed if code not testable
Discipline
Will you really write the tests later?
55
Innovation for a smarter planet
56. IBM Software Group | Rational software
BDD
“Why practice TDD when you can practice BDD?”
BDD extends TDD
Involves stakeholders, not just developers
Even harder to implement.
56
Innovation for a smarter planet
57. IBM Software Group | Rational software
ATDD, BDD, GOOS
Many shades of outside-in, test-first development
57
Innovation for a smarter planet
58. IBM Software Group | Rational software
None of these are enough either
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then check that the account is debited
And check that cash is dispensed
And check that the card is returned
“And check that nothing happens that shouldn’t happen and
everything else happens that should happen for all variations
of this scenario and all possible states of the ATM and all
possible states of the customer’s account and all possible
states of the rest of the database and all possible states of the
system as a whole, and anything happening in the cloud that
should not matter but might matter.”
58
Innovation for a smarter planet
59. IBM Software Group | Rational software
Manual testing
“It is much faster to just think about the proper
implementation, write the code and manually test it.”
Until you need to do it again
… and again
Manual scripts
Error prone
Time consuming
Expensive
59
Innovation for a smarter planet
60. IBM Software Group | Rational software
Agenda
Motivation
Education
Inappropriate project
Cultural
Time pressures
Unclear benefits
Wrap up
60
Innovation for a smarter planet
61. IBM Software Group | Rational software
Not sufficient, but necessary?
TDD is not enough. Consider:
Acceptance
Usability
Performance / Stress
Exploratory
Systems have been, and continue to be, successfully
delivered without TDD.
But they have also been delivered without designs, documentation, or
…. testing of any kind.
61
Innovation for a smarter planet
62. IBM Software Group | Rational software
Conclusions
There are many impediments to adopting TDD
Benefits are not universally accepted
TDD is not a “Silver Bullet”
62
Innovation for a smarter planet
63. IBM Software Group | Rational software
Essential Reading
Test Driven Development by Example – Kent Beck
Growing Object Oriented Software Guided By Tests – Steve
Freeman/Nat Pryce
Working With Legacy Code – Michael Feathers
Fearless Change – Mary Lynn Manns/Linda Rising
JUnit Recipes – J.B. Rainsberger
63
Innovation for a smarter planet
64. IBM Software Group | Rational software
Other references
Fluff Driven Development:
http://www.threeriversinstitute.org/blog/?p=594
Presenter First:
http://atomicobject.com/files/PresenterFirstAgile2006.pdf
TDD in C:
http://www.pvv.org/~oma/TDDinC_Smidig2007.pdf
On the effectiveness of Test-first approach to Programming:
http://nparc.cisti-icist.nrc-
cnrc.gc.ca/npsi/ctrl?action=rtdoc&an=5763742&article=0&lang=
en&ext=pdf
64
Innovation for a smarter planet
Editor's Notes
1987 – “Test, then code” – 4th Int. Conf. Software Testing, Washington, DC
Not enough personnelCancelled projectsOverrunsLarge projects more likely to overrun¾ all large systems have operational failures
Gladwell - outliers
Literate programming is an approach to programming introduced by Donald Knuth as an alternative to the structured programming paradigm of the 1970s
Emergent Design is a consistent topic in Agile Software Development, as a result of the methodology's focus on delivering small pieces of working code with business value. With Emergent Design, a development organization starts delivering functionality and lets the design emerge. Development will take a piece of functionality A and implement it using best practices and proper test coverage and then move on to delivering functionality B. Once B is built, or while it is being built, the organization will look at what A and B have in common and refactor out the commonality, allowing the design to emerge. This process continues as the organization continually delivers functionality. At the end of an agile or scrum release cycle, Development is left with the smallest set of the design needed, as opposed to the design that could have been anticipated in advance. The end result is a smaller code base, which naturally has less room for defects and a lower cost of maintenance[1].As Emergent Design is heavily dependent upon Refactoring, practicing Emergent Design without a comfortable set of unit tests is considered an irresponsible practice.
See answer by Cellfish -http://stackoverflow.com/questions/1715822/unit-test-for-thread-safe-ness/1746652