Nimble Work Management
Kairon - Gen AI Solutions
AKT/ AKC Access
→ Agile Methodology
→ Agile Software Development
→ Agile Program Management
→ Scrum Methodology
→ Kanban Methodology
→ Extreme Programming (XP)
→ Behaviour Driven Development (BDD)
→ Feature Driven Development (FDD)
→ Adaptive Software Development (ASD)
→ Dynamic System Development Method (DSDM)
→ Sustainable Pace
→ Story Mapping
→ Test Driven Development
→ Acceptance Test Driven Development
→ Iterative & Incremental Development
→ Pair Programming
→ Unit Testing
→ Acceptance Testing
→ Agile Planning
→ Refactoring in Agile
→ Burndown Chart
→ Lead Time & Cycle Time
→ Agile Velocity
→ Definition of Done
→ Backlog Refinement
→ User Stories
→ Scaled Agile Frameworks
→ Large Scale Scrum (LeSS)
→ Scrum of Scrums
→ Agile Release Train
→ Is SAFe Agile?
→ SAFe Implementations
→ Enterprise Agility With SAFe
→ What is Project Management Lifecycle?
→ What is a Project Management Office (PMO)?
→ What is Agile Project Management?
→ Importance of Project Management
→ What is a Project Roadmap?
→ What is Resource Management?
→ What is Work Management?
Test Driven Development is a process in which you write the test before you write the code. And when all tests are passing you clean your kitchen: you make the code better.
Yet, Test Driven Development Is Not About Testing
The premise behind test driven development, according to Kent Beck, is that all code should be tested and refactored continually. That sure sounds like it’s about testing, so what gives?
Well, the tests you write in TDD are not the point, but the means.
The point is that by writing tests first and striving to keep them easy to write, you’re doing three important things
Yes, there are good reasons not to let developers write the tests to test their own code.
However, this advice applies to application level tests.
For developer level tests, getting someone else to write the tests is like hitching the horse behind the wagon.The requirements usually are several abstraction levels above that of the code needed to implement it. So you need to think through what you need to do and how you’ll do it. Writing the tests first is an excellent, and efficient, way to do that.
And, remember, TDD is not about testing.
Back in 1996, the C3 project team at Chrysler practiced test-first programming. “We always write unit tests before releasing any code, usually before even writing the code.” says the case study on the project titled “Chrysler Goes to “Extremes”.
Writing tests first was just one of the practices used by the C3 team. Taken together, these practices became known as eXtreme programming. Three members of that team, Kent Beck, Martin Fowler, and Ron Jeffries, were among the people that wrote and first signed the Agile Manifesto.
Test driven development is a core Agile practice. It directly supports the Agile value of “Working software over comprehensive documentation”. And does so by protecting working software with tests and creating the documentation as a natural by-product.
Uncle Bob (Robert C. Martin) set out the rules of TDD in chapter 5 Test Driven Development of his book The Clean Coder.
Sometimes you’ll find opportunities to refactor test code. For example when you have a bunch of separate [Fact] tests in xUnit that only differ in the arguments they pass to the method under test. You can replace these with a single [Theory] test.
My advice: don’t refactor, but add the theory and when that is in agreement with the facts, you can remove the facts.
When you refactor, you don’t do it haphazardly. But you follow a structured process to clean up the code.
You identify code smells and apply a specific refactoring to remove it. Martin Fowler wrote the book on how to do it: Refactoring: Improving the Design of Existing Code.
The purpose of refactoring is to improve the extensibility of your code by
Humanize Work. And be Nimble!