Bootcamp Day 3
It was a beautiful Tuesday, the 3rd day of the boot camp 11/10/2016. I learn how to use Test Driven development in Python
Test Driven Development
Test-driven development (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.
The primary goal of TDD is the specification and not validation (Martin, Newkirk, and Kess 2003). In other words, it’s one way to think through your requirements or design before your write your functional code (implying that TDD is both an important agile requirements and agile design technique). Another view is that TDD is a programming technique. As Ron Jeffries likes to say, the goal of TDD is to write clean code that works. I think that there is merit in both arguments, although I lean towards the specification view, but I leave it for you to decide.
Test-driven development cycle
1. Add a test
In test-driven development, each new feature begins with writing a test. Write a test that defines a function or improvements of a function, which should be very succinct. To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through use cases and user stories to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. It could be a modified version of an existing test. This is a differentiating feature of test-driven development versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference.
2. Run all tests and see if the new test fails
This validates that the test harness is working correctly, that the new test does not mistakenly pass without requiring any new code, and that the required feature does not already exist. This step also tests the test itself, in the negative: it rules out the possibility that the new test always passes, and therefore is worthless. The new test should also fail for the expected reason. This step increases the developer’s confidence that the unit test is testing the correct constraint, and passes only in intended cases.
3. Write the code
The next step is to write some code that causes the test to pass. The new code written at this stage is not perfect and may, for example, pass the test in an inelegant way. That is acceptable because it will be improved and honed in Step 5.
At this point, the only purpose of the written code is to pass the test. The programmer must not write code that is beyond the functionality that the test checks.
4. Run tests
If all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.
5. Refactor code
The growing code base must be cleaned up regularly during test-driven development. The new code can be moved from where it was convenient for passing a test to where it more logically belongs. Duplication must be removed. Object, class, module, variable and method names should clearly represent their current purpose and use, as extra functionality is added. As features are added, method bodies can get longer and other objects larger. They benefit from being split and their parts carefully named to improve readability and maintainability, which will be increasingly valuable later in the software lifecycle. Inheritance hierarchies may be rearranged to be more logical and helpful, and perhaps to benefit from recognized design patterns. There are specific and general guidelines for refactoring and for creating clean code.[6][7] By continually re-running the test cases throughout each refactoring phase, the developer can be confident that process is not altering any existing functionality.
The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to the removal of any duplication between the test code and the production code — for example magic numbers or strings repeated in both to make the test pass in Step 3.
Repeat
Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert in preference to excessive debugging. Continuous integration helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself,[4] unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to serve all the needs of the software under development.
Advantages of Test Driven Development
1. Writing tests first require you to really consider what you want from the code
2.Short feedback loop
3.Creates a detailed specification
4.Reduced time in rework
5.Less time spent in the debugger and when it is required you usually get closer to problem quickly
6.Tells you whether your last change (or refactoring) has broken previously working code
7. Allows the design to evolve and adapt to your changing understanding of the problem.
8. Simplification
i) Forces radical simplification of the code — you will only write code in response to the requirements of the tests.
ii)Forces you to write small classes focused on one thing.
Help create loosely coupled code
iii)Creates SOLID code (Articles: Bob Martin and Chad Myers)
iv) The resulting Unit Tests are simple and act as documentation for the code
v) Improves quality and reduces bugs by:
a) forcing us to consider purpose (and the specification of code)
b) simplifying code (many bugs come from the complexity)
c)ensuring changes and new code don’t break the expectations of existing code
Disadvantages?
TDD is hard to learn, especially on your own. You can expect reduced productivity for 2–4 months after starting.
Test Driven Development in Python
The process can be defined as such:
1. Write a failing unit test
2. Make the unit test pass
3. Refactor
Test in python
Hope the information above was helpful
All the best