Whats the difference between tdd and automated tests?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

...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.