I'm new to TDD and wondering about methodolody.Given: A simple project which implements functionality of, for example, a console calculator.It has the following structure: Fairly simple top-level class that takes console input, delegates it to a buisness-logic class and shows output in the console with some fancy formatting.The forgoing buisness-logic class which does all the calculations and which is relatively complex.Also let's assume we have a nice thorough suite of acceptance tests for the whole project, which performs through the user interface.Do I need a suite of unit tests for inner business-logic class? Since it's going to replicate the acceptance test suite for 90%.Additional, but closely related questions:Will the answer for the question remain the same if, for example, that acceptance test suite takes 30 sec to run? 5 mins? 1 hour?If the inner business-logic class is not yet implemented, do I need write that suit of unit tests to guide its development, or it's fine to remain only with acceptance tests?
Do I need a suite of unit tests for inner business-logic class? Since it's going to replicate the acceptance test suite for 90%
unit testing;tdd;acceptance testing
Do I need a suite of unit tests ...Unit tests are no end in itself - you should better ask Do I need a suite of unit tests if I want to reach a certain goal. If your goal is just to make sure the software you are writing behaves correctly as a black box from outside, you only need acceptance tests. But if your goal is also that your business-logic is properly structured into small components (instead of one big god class), and each of that components should behave correctly, then you will need unit tests for each of that components. The reason for having components is that this keeps your software more evolvable (it will become easier to add new requirements) and more maintainable (when you added a new requirement, and you had to change the existing code, and your acceptance tests shows that you introduced a bug, the unit tests might help you to spot the root cause of that bug more quickly).So the gist is - unit tests make only sense in the presence of units.If the inner business-logic class is not yet developed, do I need write that suit of unit tests to guide its development?TDD is not about writing a suite of tests beforehand. It is about writing unit tests and code almost in parallel (write test - write code - refactor - rinse and repeat).EDIT (to your comment): if you have acceptance tests in place, your program works as it should, there is no direct reason to introduce unit tests yet. But, as soon when you have to change something in your code (probably because of new requirements), and you want to do TDD, then its a good idea to start writing unit tests for exactly the parts of your code you want to change (and not a full test suite). Maybe you start with a test for a function to verify its current behaviour (green). The acceptance tests will prevent you from introducing a bug in this stage. Then you modify the test or add an additional test to verify the intended behaviour (which makes your unit test red). Afterwards you add the new functionality to your function (which makes you tests green again). And now comes the important part: you check if your function has become so complex that you better refactor it now - which can be done very painlessly because of the tests you just introduced. So the idea of unit tests (in a TDD context) is not to duplicate the purpose of acceptance tests, but to help you with your actual coding and low-level design improvements.