Running TDD halfway through a project, good practice?
I am halfway through developing a large Flask web application.
In the beginning, I decided not to use test development for the learning curve for project-related reasons.
So in the last weeks I had the opportunity to learn more about it and I started using it very soon.
However, as far as my TDD project is concerned from the start, are there any downsides to start using it now?
I would not refactor my entire application, just new features that I am planning in the near future.
source to share
Quite right. This is a really great time to get involved in unit testing because your project is already up and running.
Often when starting a project, the technical requirements are not very strong and there is a lot of experimentation with the implementation. During this period, unit tests can impose a lot of time overhead. If specifications are not very solid than higher level tests, they are often more valuable. These could involve sending a test request through a public interface (the same one that will be used by the client), and generally asserting the response / data / etc. This allows service replacement under higher level tests.
The only problem I can think of starting with it is the purpose of unit testing. For me, unit testing is primarily a tool for learning how to write test code, i.e. Connections, abstractions, encapsulations, seams , etc. didn't practice writing code like this, then the opportunity to learn was wasted!
If you don't have a test harness setup, there will be the overhead of creating a directory structure, a test hierarchy including your test runner, test coverage / results report (xml), test run integration. If you are able, hosted services like travis will really reduce the effort involved in including this in your dev process.
source to share
TDD "done right" is always good practice - no matter where you start using it.
But to avoid getting into a situation where one part of the codebase tests well per unit and others don't: look for ways to go beyond just embracing new features. In other words: if time allows not only testing those parts of the file / class that the new function will go into, but instead try to turn this whole block into "tests".
The main aspect of unit tests is that they allow you to make changes to your code base without breaking the rules. Unit tests allow you to run faster. Thus, look for ways to ensure that you can transition at a "high speed" for most of your code base.
source to share
Agree with the previous answer. Yes , you can start using TDD at every single point of development.
When you try to run redline tests that should fail at the start , it should come as no surprise to you that they reveal a lack of functionality.
When you start implementing TDD on a large system with a lot of code already in you, you should first test the availability of some features by writing a test (or group of tests). Then, if it works well, you continue until the test start shows the limits of the code's potential.
I will add that if you start now and decide to cover not only the new features (but the old ones as well as the ones mentioned above), at this point you are more likely to spend more time on the old features.
And in this case, it won't be called pure TDD (just to say), as some tests will be implemented after the code is written, but if it fits the project, this is also an option (can definitely be worth it). Still, it's probably better to test something now than in the beta phase. At least because it will be easier to come across a solution if you find that something is wrong with your old functions.
So later you will experience so much harder that you decided to solve the problems. Then it takes more time. And if people use tests for a long time after the code has been written, it becomes double work as you need to rethink how your code works. Therefore, in a TDD record, tests pass almost along with writing code. Even at this point, it’s probably easier for you to remember what you coded first.
source to share