What is unit testing, and does it require writing code?

Question

I joined the new team and I had a problem understanding how they perform unit tests. When I asked where the unit tests were written, they explained that they did not perform their unit tests this way.

They explained that what they call unit tests is when they actually test the code that they wrote locally, and that all points are connected. For me, this is integration testing and local code testing.

I got the impression that unit tests are code written to test behavior in a small section of code. For example, you can write unit test to make sure it returns the correct value and make the appropriate calls to the database. use a structure like NUnit or MbUnit to help you with your statements.

Unit testing for me should be quick and fast. For me, you want you to be able to automate it, and you have a huge set of tests for your application to make sure that it behaves as YOU EXPECT.

Can someone clarify my or their misunderstandings?

Answer 1

Your assumptions are correct.

Running a project without unit tests (like them, don't be fooled) may seem enjoyable during the first few weeks: less code to write, less architecture for thought, less problems to worry about. And you can see that the code is working correctly, right?

But as soon as someone (someone else or even the original encoder) returns to an existing piece of code to change it, add a function, or just understand how it works and what it definitely did, everything becomes much more problematic. And before you realize this, you will spend nights looking at the log files and debugging what seemed like a small feature, just because it needs to integrate with other code that doesn't know exactly how it works. And you will hate your work.

If this is not worth testing (with actual unit tests), then it is not worth writing the code first. Everyone who has tried coding without and with unit tests knows this. Please, please make them change their mind. Every time a piece of unverified code is checked somewhere, the puppy dies horribly.

In addition, I must say that it is a lot (A LOT) more difficult to add tests later to the project, which was done without testing, and not from the very beginning to create test and production code. Testing will not only help you make sure that your code is working fine, but also improves the quality of the code, forcing you to make the right decisions (for example, coding on interfaces, free connection, inverting control, etc.).

Answer 2

I worked on places that tested this way and called it unit testing. It reminded me of a quote attributed to Abe Lincoln:

Lincoln: How many legs does a dog have?

Another guy: 4.

Lincoln: What if we call the tail leg?

Another guy: Well, then he will have 5.

Lincoln: No, the answer is still 4. Calling the tail, the leg does not.

Answer 3

They explained that what they call unit tests is when they actually verify the code that they wrote locally, and that all points connect.

This is not a unit test. This is a code review. Code reviews are good, but without real unit tests everything will break.

Unit tests use a write code. In particular, unit test runs on a single device, which is just a class or component of your software.

If the class you are testing depends on another class, and you are testing both classes together, you have an integration test. Integration tests are good. Depending on the language / structure, you can use the same testing environment (e.g. junit for java) for unit tests and integration. If you have a dependency, but a layout or stub for this dependency, then you have a clean unit test.

Unit testing for me should be quick and fast. For me, you want it so that you can automate it and have a huge set of tests for yours to make sure that it behaves as you EXPECT.

This is essentially correct. How “fast and fast” unit test designs depend on the complexity of the test and the skills of the developer who wrote the test. You definitely want to create a test suite over time, so you know when something breaks, when the code base becomes more complex. This is how testing makes your code base more convenient by telling you that it stops functioning when changes are made.

Answer 4

Your teammates do not conduct unit testing. They are engaged in the development of "flying in the place of your pants."

Answer 5

"Unit testing"! = "Unit tests".

Unit testing is one specific unit testing method. This is very good, and if your unit tests are well written, it can give you good value for a long time. But what they do is unit testing. This is just unit testing that won't help you at all the next time you need to cut the same code. And it is wasteful.

Answer 6

To add my two cents, yes, this is really not unit testing. IMHO, the main features of unit tests are that they must be fast, automatic and isolated. You can use a mocking structure such as RhinoMocks to isolate external dependencies.

Unit tests should also be very simple and short. Ideally, nothing more than the length of the screen. It is also one of the few places in software development where copying and pasting code can be a better solution than creating reusable and abstract abstract functions. The reason for simplicity is such a high priority to avoid the problem of "Who is watching the observers." You really do not want to be in a situation where you have complex errors in unit tests, because they themselves are not tested. Here you rely on the extreme simplicity and tiny size of the tests to avoid mistakes.

Unit test names should also be very descriptive, again after simplicity and a self-documenting paradigm. I must be able to read the name of the testing method and know exactly what it does. A quick glance at the code should accurately show which functions are being tested and which external bullying is ridiculed.

Descriptive test names also make you think of the application as a whole. If I look at the entire test run, ideally, just by looking at the names of all the tests that were run, I should have a good idea about what the application does.