Test Development - What is a Test?

Question

I found out what TDD is, and one question that comes to mind is exactly what a “test” is. For example, do you call a web service and then create code to make it work? or is it more focused on unit testing?

Answer 1

In general, the test may be ...

• unit test , which tests a separate subcomponent of your software without any external dependencies with other classes
• integration test , which are tests that test the connection between two separate systems, i.e. their integration capabilities
• acceptance test to verify system functionality.

... and some others that I most likely temporarily forgot at the moment.

In TDD, however, you mainly focus on unit tests when creating your software.

Answer 2

It is fully unit test driven.

The main idea is to write unit tests first and then do the absolute minimum amount of work needed to pass the tests.

Then write more tests to cover more requirements, and do a little more to get through.

This is an iterative process with test write cycles and then coding.

Answer 3

Here are some good articles from Unclebob

Three TDD Rules

TDD with acceptance and unit tests

Answer 4

I suggest you not emphasize Test , because TDD is actually a software development methodology, not a testing methodology.

Answer 5

I would say that we are talking about unit testing and code coverage. It is about delivering code without error and the ability to easily make changes in the future.

See "Uncle Bob" words of wisdom .

Answer 6

As I use it, it focuses on unit testing. Suppose I want a method that has square ints, I write this method:

int square(int x) { return null; } 

and then write some tests like:

 [Test] TestSquare() { Assert.AreEqual(square(0),0); Assert.AreEqual(square(1),1); Assert.AreEqual(square(10),100); Assert.AreEqual(square(-1),1); Assert.AreEqual(square(-10),100); .... } 

Well, maybe a square is a bad example :-)

In each case, I check the expected behavior and all the boundary shafts, such as maxint and zero and zero value (remember that you can also check for errors) and see that the test fails (which is not difficult :-)), then I continue work on a function until it works.

So: first a unit test, which does not allow you to cover what you want to cover it, then a method.

Answer 7

Typically, unit tests in "TDD" should not include any I / O at all.

In fact, you will have more efficiency if you write objects that do not create side effects (I / O almost always, if not always, a side effect!) And determine the behavior of your class either in terms of return values ​​of methods or calls made to interfaces that were passed to the object.

Answer 8

I just want to give my opinion on a topic that can help to understand TDD a little differently.

TDD is a design method that primarily relies on testing. because you asked how the test goes, do the following poorly:

If you want to create an application, you know the purpose of what you want to build, and you usually know that when you are done, or along the path that you need to check, for example, check the values ​​of the variables that you create by code, inspect, quickly release the button , which you can click on and execute part of the code, and you will see a dialog to show the result of the operation, etc.

TDD, on the other hand, changes your mindset, and I will point out one of these ways. usually you just rely on a development environment such as visual studio to detect coding and compilation errors and somewhere in your head, you know this requirement and simply code and test using buttons and pop-ups or code verification. I call this style SDDD (Syntax Debugging Development). but when you do TDD, it's “semantic debugging” because you first write down your thoughts / goals for your application using tests (which are a more dynamic and repeatable version of the whiteboard) that checks the logic (or “semantic”) of your application and fails whenever you have a semantic error, even if the application passes a syntax error (when compiling).

Answer 9

by the way, although I said: “You know the purpose of what you want to build ..”, in practice you may not know or have all the information necessary to create an application, since the TDD type forces you to write first, you are forced to ask more questions about the functioning of the application at an early stage of development, rather than building a lot, only to find out that much of what you wrote is not required (or the moment does not allow). you can really avoid wasting your precious time on TDD (even if it may not be the way it was originally)