Test-Driven Development (TDD) is a software development methodology that involves writing tests for your code before writing the code itself. This ...
For further actions, you may consider blocking this person and/or reporting abuse
Depends a lot on the project, not all projects can use TDD/BDD........effectively, it is good especially when you know exactly the requirements/needs, and have clear vision and goals
Totally agree Aghiles.
Learning how to balance the use of testing is also a very important skill to develop.
If you are simply working on a prototype or something that won't live very long it could be unnecessary to use TDD or even write tests at all.
That said, adding TDD as a common practice in my routine was a powerful advantage that helped me develop a better testing mindset. It made me think more about little steps to deliverables and find better solutions, even if I don't write tests I am still constantly approaching development with it in mind.
"It made me think more about little steps to deliverables and find better solutions" I agree with that it makes you write offensive tests rather than defensive only.
But I want to know what you think about a project or a feature in a BIG project which is not a common one, but serious project, that is hard to test because we don't know how we should do it, what tools to use, what's the solution, how we can optimize it...etc Would you still use TDD ? For me it's a big No because you don't even know what to write in the test, you are still figuring out something (idk if i'm clear haha^^)
I know for example that lot of features at Netflix can't use TDD at all because of that, and what they do is once the feature is done and they are happy with the result, they write very smart defensive tests and maybe offensive if it's possible, but the main goal is to eliminate regressions, which is still one of the main goals of TDD, being sure that when code is changing it's not breaking something done in the past
To be very honest, this case you suggested is actually the type of thing I would strongly try to rely on TDD. The reason behind it is that it would force me to first understand the problem completely and clearly define what I am trying to achieve before writing random code.
Working on a large codebase is definitely challenging to apply TDD, but it is completely possible and that will even help you to discover places that you can refactor and decouple.
In terms of tools it is actually very simple. It is not so much about the tools you use, but more about the practices you follow. The way I like to approach it is by having a very general conversation about what needs to be done and list what is the expected behaviour of the feature I need to work on.
For example, you could use an outside-in approach where you first list some scenarios like: "given an input X expect output Y".
Or you could follow and inside-out approach, where you focus first in the core domain of what you are building and start expanding (works wonderfully with DDD btw).
In the end, these suggestions are not the only possible path to a successful career and they strongly depend on the environment that you work on, your style of work and if you really like it or not (which you can only know after trying lol).
In which cases is not effective to use TDD?
I found that TDD is not very effective in cases like:
I found that apps that are not very interactive may also be worthless to built with TDD, but this and all of the cases above vary a lot based on your current situation.
Another important thing is that trying to learn TDD by applying in your current job is also very complicated. Starting with TDD requires a lot of effort in the beginning and that will definitely slow you down and it may make you give up on this practice. My suggestion in this case is to start learning with personal projects first and slowly start including it in your main job routine.