Anti-patterns Test Driven Development
I hope that as a competent developer, you have an idea about unit testing and make yourself a couple of mental notes about what should be avoided when writing tests. Meet:
A unit test that successfully performs all the cases and looks to work correctly, however, on a closer look, it appears that it does not actually test what it should.
A test that requires hard initialization work before you start the actual testing. Sometimes it happens to see hundreds of lines being invoked for a single test, while creating multiple objects. Because of this “noise,” it is difficult to ascertain what is being tested.
')
A unit test that, although correctly testing an application, spreads over thousands of lines of code and contains too many cases. This may indicate that the system under test is the anti-pattern Almighty Object (God Object).
Mocking can be very convenient and correct. But it happens that developers lose their sense of proportion and use it even for those parts of the system that, in principle, should participate in testing. In this case, the unit test contains so many mocks, stubs and fakes that part of the system remains untested.
Unit test that breaks encapsulation in an attempt to achieve 100% of code coverage (code coverage) and at the same time knows too much about the system under test. When refactoring a system, such a test breaks down too often and requires corrections.
The case when one unit test creates data that is saved somewhere, and another test reuses it later. If the “data generator” is for some reason called later or skipped, the test using its data will not pass.
A test that depends on something specific to a given environment. As a result, the test successfully passes a specific developer, but is not performed by others.
Unit-test, which checks the entire result of the work, while in fact only its small part is important. As a result, you have to frequently update the test to reflect changes in minor things. Typical when testing web applications.
The test, which at first glance does not do any testing due to the lack of assertions, but in fact pulls the strings of the system and relies on throwing out some kind of exception in case of problems. The test environment is expected to catch this error and display the test as failed.
Unit-test, which tests a lot of minor (and, as a rule, simple) trifles, but does not test basic behavior.
Unit-test, which clogs the console with a variety of diagnostic messages, logs and other information, even if the test passes successfully. Sometimes it is the result of unnecessary code that was not removed after debugging the test.
A test that catches exceptions and “swallows” them, either by replacing it with a less informative message, or simply outputting an error to the console, allowing the test to complete successfully.
A test that depends on the fact that the actual unordered data always appears in the same order.
A close relative of the Local Hero. This is a unit test that requires that you fill in some data before starting. If this data is missing, then the test falls, leaving little information about the cause of the problem and forcing the developer to dig into a pile of code in order to determine what data and where they should have come from.
Unit test, in which all cases are poorly named (for example, test1, test2, test3). As a result, the purpose of the test case is unclear and the only way to understand what has broken is to climb into the test code and pray that it will be understandable.
A case that does not belong to the unit test in which it is located. It actually tests a completely different object, most often an object that is used by the main object being tested. Also known as Distant Relative.
Unit test that relies on the features of a specific operating system. A good example would be a test that waits for a line break accepted in Windows and broken when executed under Linux.
A test that was written to pass successfully, and not to fail first (fail first principle). A side effect is not enough in-depth testing and successful completion where the right test should fall.
Instead of writing a new case method, simply add a new assert to the existing case.
The combination of several anti-patterns, especially the Hare and the Giant. Such a unit-test consists of a single method that tests all the functionality of the volume. A typical indicator of a problem is the name of a test method called a unit test and a large number of initialization strings and asserts.
A test that, due to shared resources, can see data from other tests and may fall even if the system under test is completely valid. A typical example is the use of static fields to store collections. If they are not properly cleaned, then unexpected side effects are possible in other tests. Also known as the anti-pattern Unidentified Guests.
Unit test, which runs extremely slowly. When a developer launches it, he gets enough time to go to the toilet or smoke. Or, which may be even worse, he will not wait for the completion of testing before he closes in the evening and goes home.
From the translator: admiration with clever thoughts — author, kicks for translation — me. :)
Liar (The Liar)
A unit test that successfully performs all the cases and looks to work correctly, however, on a closer look, it appears that it does not actually test what it should.
Excessive Initialization (Excessive Setup)
A test that requires hard initialization work before you start the actual testing. Sometimes it happens to see hundreds of lines being invoked for a single test, while creating multiple objects. Because of this “noise,” it is difficult to ascertain what is being tested.
')
Giant
A unit test that, although correctly testing an application, spreads over thousands of lines of code and contains too many cases. This may indicate that the system under test is the anti-pattern Almighty Object (God Object).
The Mockery
Mocking can be very convenient and correct. But it happens that developers lose their sense of proportion and use it even for those parts of the system that, in principle, should participate in testing. In this case, the unit test contains so many mocks, stubs and fakes that part of the system remains untested.
The Inspector
Unit test that breaks encapsulation in an attempt to achieve 100% of code coverage (code coverage) and at the same time knows too much about the system under test. When refactoring a system, such a test breaks down too often and requires corrections.
Generous Leftovers
The case when one unit test creates data that is saved somewhere, and another test reuses it later. If the “data generator” is for some reason called later or skipped, the test using its data will not pass.
Local Hero (The Local Hero)
A test that depends on something specific to a given environment. As a result, the test successfully passes a specific developer, but is not performed by others.
Krohobor (The Nitpicker)
Unit-test, which checks the entire result of the work, while in fact only its small part is important. As a result, you have to frequently update the test to reflect changes in minor things. Typical when testing web applications.
Secret Catcher (The Secret Catcher)
The test, which at first glance does not do any testing due to the lack of assertions, but in fact pulls the strings of the system and relies on throwing out some kind of exception in case of problems. The test environment is expected to catch this error and display the test as failed.
The Dodger
Unit-test, which tests a lot of minor (and, as a rule, simple) trifles, but does not test basic behavior.
Screamer (The Loudmouth)
Unit-test, which clogs the console with a variety of diagnostic messages, logs and other information, even if the test passes successfully. Sometimes it is the result of unnecessary code that was not removed after debugging the test.
The Greedy Catcher
A test that catches exceptions and “swallows” them, either by replacing it with a less informative message, or simply outputting an error to the console, allowing the test to complete successfully.
The Sequencer
A test that depends on the fact that the actual unordered data always appears in the same order.
Hidden Dependency
A close relative of the Local Hero. This is a unit test that requires that you fill in some data before starting. If this data is missing, then the test falls, leaving little information about the cause of the problem and forcing the developer to dig into a pile of code in order to determine what data and where they should have come from.
Counter (The Enumerator)
Unit test, in which all cases are poorly named (for example, test1, test2, test3). As a result, the purpose of the test case is unclear and the only way to understand what has broken is to climb into the test code and pray that it will be understandable.
The Stranger
A case that does not belong to the unit test in which it is located. It actually tests a completely different object, most often an object that is used by the main object being tested. Also known as Distant Relative.
OS Devotee (The Operating System Evangelist)
Unit test that relies on the features of a specific operating system. A good example would be a test that waits for a line break accepted in Windows and broken when executed under Linux.
Success Against All Odds
A test that was written to pass successfully, and not to fail first (fail first principle). A side effect is not enough in-depth testing and successful completion where the right test should fall.
The Free Ride
Instead of writing a new case method, simply add a new assert to the existing case.
The One (The One)
The combination of several anti-patterns, especially the Hare and the Giant. Such a unit-test consists of a single method that tests all the functionality of the volume. A typical indicator of a problem is the name of a test method called a unit test and a large number of initialization strings and asserts.
The Peeping Tom
A test that, due to shared resources, can see data from other tests and may fall even if the system under test is completely valid. A typical example is the use of static fields to store collections. If they are not properly cleaned, then unexpected side effects are possible in other tests. Also known as the anti-pattern Unidentified Guests.
Brake (The Slow Poke)
Unit test, which runs extremely slowly. When a developer launches it, he gets enough time to go to the toilet or smoke. Or, which may be even worse, he will not wait for the completion of testing before he closes in the evening and goes home.
From the translator: admiration with clever thoughts — author, kicks for translation — me. :)
Source: https://habr.com/ru/post/43761/
All Articles