Whats the difference between tdd and automated tests? I'm confused.

  • Search for TDD and Kent Beck.
    – Kain0_0
    Oct 30, 2019 at 22:49

3 Answers 3


Automated Tests are tests that are automated, i.e. tests that don't have to be performed manually.

Test-Driven Development is a Software Development Methodology in which Tests drive the entire development process. In order to drive the process, writing tests needs to be the very first thing you do; when you have written a failing test, the test tells you what code to write, which code to write next, and when you are finished writing code. The tests are the driver for the entire development process.

The two don't really have anything to do with each other (apart from the fact that typically, the tests used in TDD are automated tests), so asking about their difference is about as meaningful as asking about the difference between a Toyota Corolla and the color blue.

  • Thanks!! Where should I get started learning about automated tests in Java?
    – Frank
    Nov 1, 2017 at 3:14
  • @frank Maybe dive in with one of the frameworks - Junit is one of the better known ones.
    – Robbie Dee
    Nov 1, 2017 at 8:56
  • Where should I start learning testing and going beyong? I use Java. Thanks!
    – Frank
    Nov 1, 2017 at 20:25

Automated Tests

... are mini programs that execute some code against some input/environment and verifies that some output/outcome was achieved.

  • Unit Tests evaluate a function/class using mocks for every collaborator.
  • Integration Tests verify that two pieces of code co-operate together correctly. Such as integrating with a Database, accessing the File System, network connection handling, etc...
  • Module tests verify a larger unit of complex behaviour. They are large enough to have some long lasting environmental state, hide highly orchestrated complex calculations, or have a complex protocol for being interacted with.
  • E2E (end to end) tests are lifecycle tests where every piece of the system is deployed (in a test environment) and strung up with most (if not all) of its collaborating systems. These tests often describe actual business use cases, but also need to include verification of the automated business as usual and support scenarios.
  • Performance tests execute a piece of code several times to characterise its runtime behaviour. That could be for speed, for stability, for capacity, or even attack scenarios (like Denial of Service simulation). The test passes if the code performs within some expected limits.

There are other categories of automated test that focus less on the how it is being tested, and more on the purpose of the test (such as Dev tests, Acceptance Tests, defect tests).

Test Driven Development (TDD)

Is a design methodology where by:

  • while not yet done...
    • write a test that describes the expected behaviour of an interface.
    • write the actual code that satisfies the described behaviour.

This forces you to think through the interface, and how that interface will be used later.

This can be a very powerful technique, but you should use it in reason. I recommend researching Kent Beck (the father of TDD) along with his discussion on "the Three Xs" (Explore, Expand, Extract).

Just to note, there is a qualitative difference between the tests written using TDD and tests written post-implementation.

  • Those tests written using TDD will be very complete descriptions of expected system behaviour, even to the point of being better than documentation. And do serve to prove that the system is capable of performing in the expected manner.
  • Those tests written post-implementation will not be very good descriptions on how to use the system, but can actually be written in an adversarial manner. That is you can read the implementation and specifically search for edge cases, or poor implementation choices and hammer them punatively.
  • Good answer - although I never liked describing TDD as a way of thinking through interfaces. To me, it's more about defining natural test boundaries through semantically meaningful behavioural units. This is super helpful when you later need to refactor by breaking out components, because it leads to those interfaces being generally more stable than if you're just "writing tests for classes."
    – Ant P
    Oct 31, 2019 at 9:42

...so asking about their difference is about as meaningful as asking about the difference between a Toyota Corolla and the color blue...

This is not true as there is a massive difference. TDD is counterproductive and places all the onus and testing responsibility on the developer. This goes against the "tester" specialization and the fact that a developer should never be the only one to test his own code. It also place a tremendous amount of undue pressure on the developer. I have written code so complex that if I followed TDD it would have taken more than twice the time to develop.

Test automation on the other hand is completely different. While TDD can be a form of test automation typically there are other tools that "testers" use to record user sessions and code in certain behaviors using tools like Visual Studio and C#.

The "tester" specialist can be far more efficient in test automation for 2 reasons. Firstly this takes the pressure off the developer. Secondly this shares the workload where the onus is on the "tester" to do the test automation rather than burdening the developer whom already has too much work to do. He does that easily with a combination of recording end user data inputs and C# code for testing automation purposes. This is a far more efficient and superior solution to TDD.

I would go as far as to say that unless your software application is relatively simple (which is rare) stay away from TDD. Find a good tester whom can record and code test automation for the developers. Alternatively developers themselves could use tools like Visual Studio and C# to record and code the test automation which would still be more efficient than TDD.

  • So the back-and-forth between tester and developer is more efficient than a developer encountering most of those problems while writing code? There is nothing wrong with having a tester. There is also nothing wrong with testers writing automated tests, but those will be full integration tests that won't verify the behavior of individual units of code (e.g. methods). Oct 30, 2019 at 22:59
  • 1
    There is nothing in TDD that would preclude having a dedicated tester designing, writing, and executing a suite of automated tests on a codebase which was written by a developer using TDD. TDD is a software development methodology, not a quality assurance methodology.
    – Eric King
    Oct 30, 2019 at 23:18
  • Still do not agree. TDD is counter productive and a tremendous effort would be needed for complex code. I do my own unit testing using debug mode which is far easier and quicker. There was life before TDD and I never needed it then, and I certainly do not need it now either. In my opinion TDD is costly, time consuming and completely unnecessary.
    – North Gork
    Nov 4, 2019 at 0:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.