TDD and Unit Testing for short projects with small teams?
Good TDD approach for small and short projects done in small groups of up to 4 people? Is this really a profitable endeavor?
How about unit testing? TDD means Unit Testing, but not vice versa. Wouldn't unit testing be done from time to time throughout the project development lifecycle to reasonable code coverage?
source to share
For me it doesn't boil down to a small or a short project. TDD, done right, is the ability to quickly run a suite of tests that provide complete confidence in your code. Much has also been written about TDD, helping to supplant appropriate design for projects as well.
So, you can argue that TDD is best for small and short projects because you end up with only the code you need to pass the tests and nothing else. Thus, cost reduction. Then there is the added benefit of having confidence in the tests and code when you make changes later.
The next small point I would make is that many projects start small and short. These intermediate solutions can become strategic platforms for development (if successful).
source to share
I recently read a good blog post by Szymon Pobiega called if you do not ... a TDD . I really recommend taking a look at this. This is because I am a bit skeptical about TDD and put it in great development lifecycle habits as the ultimate security solution for your projects, beyond the nature of the project. I like this snippet:
TDD is most useful when you are completely unaware of the shape of the code. In that case, you better not crack the code as quickly as you can. Instead, take one small step at a time, checking the outcome each time. Ideally, do it in pairs. Each step you take allows you to find out more tests to write. I love the analogy Dan used in his presentation: his, like swimming against walking 1.50 meters deep in the pool. You can go all the way, ensuring that every time one of your feet is on the ground, or you can just swim, which is more risky (no ground contact) but makes you move much faster. TDD is like walking.
It refers to the Dan North session from NDC 2012 .
source to share
Answer: YES! And for the following reason. Imagine the following scenario. You and your project team created a great application and decided to put it into production. After a while, the user comes to you saying: "Hi guys, I found a bug in your application, can you fix it please? Of course you say yes fix the bug and the user is happy. Only after a while does he come back, noticing that you fixed the problem, but now something that actually worked can't fix it anymore?
If you used TDD and did unit tests for your application, the scenario would not be like this. This is because you have tests performed for your entire application. After fixing the error, you simply run the unit tests again to see if your "fix" breaks any other things in your application.
This answer focuses more on using unit tests. Below is a description of the TDD itself.
What TDD makes you individual, think about what I will code next (object, class, function, etc.). Also, what are the edges of my code, what if / else statements are needed, what do I need to check. Whether you are on your own or on a 20-person project team, it doesn't really matter. Dealing with TDD is a process of thinking that you are not other people in your project.
source to share
If you are doing UnitTesting, this is just a small step for TDD acceptance. But you will benefit much more from this.
Just one example: TDD determines that you run your tests first. This implies that you think about the goal you want to achieve before you start implementing it. This leads to better code.
source to share
TDD and Unit Testing are not alternatives to each other. In every project you should test your code, this is where you unit test and integrate and test the system.
TDD is, however, a development model. Like Waterfall and other development methods, TDD is also a method. In TDD, you have some basic requirements, and you write unit tests to ensure that the requirements are met and work. But when you write unit tests, you realize that you need to implement more functions and classes to achieve the basic requirements. Thus, unit tests in this context simplify other requirements.
Suppose you need to write an application that prints the name of the computer that the application is running on. First, you write a unit test:
[Test]
public void ProducedMessage_IsCorrect()
{
AreEqual(BusinessLibrary.ProduceMessage(), System.Environment.MachineName);
}
and then you realize that you need to implement the ProduceMessage function. You will implement it as easily as before the unit test passes. You write the method like this:
public string ProduceMessage()
{
return "MyComputer";
}
Then you run the test and it passes. After that, you submit your code and the other team members receive the code. When they run the test, the test fails because you hard-coded your computer's name into the code.
So, some wise member of your team changes the code to the correct form and you continue.
It's all about choosing developers who have TDD experience. At least some of them must be experienced TDD developers I think.
source to share