Preface:
Most of the developers I’ve met aren’t that keen on testing. Some test, but most don’t test, don’t want to test, or try to. I love testing and happily spend more time testing than writing new code. I believe that by focusing on testing, I can spend less time writing new code or fixing bugs and be very productive.
If you’re not sure whether to write tests, or if you don’t write tests often, the following will guide you in a better direction.
Body:
1. No tests
It’s easy to fall into this trap for no reason. Starting now, make plans to add tests to the code you’re working on now and to add tests to future projects.
2. Not starting testing from the beginning of the project
It’s hard to go back and add tests, and you might need to change the architecture to add tests, which will ultimately take you longer to produce trusted code. Adding tests throughout the project lifecycle from the start saves time and effort.
3. Write failed tests
The popularity of TDD has brought red-green-refactoring to the world of software testing. The idea is often mistaken for “start by writing a test that fails.” Not really. The purpose of creating tests before writing code is to define what the correct behavior of the system should be. In many cases, it is a failed test (shown in red), but it may be represented by an inconclusive or unimplemented test.
4. Worry about not implementing tests
One of the big problems in software development is the gap between the code and any documentation about what the system is actually supposed to do. By having a test whose name clearly defines the desired behavior that you ultimately want to implement, you’ll get some value out of your tests, even if it’s not yet clear how they will be written.
5. Not naming tests well
Naming software is notoriously hard to do well, and the same applies to testing. There are several popular conventions for how to name tests. It doesn’t matter which one you use, as long as you use it consistently and describe exactly what you’re testing.
6. Make tests do too much
Long, complex names are usually a sign that you want to test several things at once. A single test should only test one thing. If you fail, you should note in your code what went wrong. You don’t have to look at which parts of the test failed in order to know what went wrong in the code. This doesn’t mean you shouldn’t have multiple assertions in your tests, but they should be closely related. For example, a test that looks at the order-processing system output and verifies whether there is a single item in the output and whether it contains a specific item is OK. But a test that validates the output of the same system, both creating a specific item, logging it to the database, and sending confirmation emails, does not.
7. No actual test code
It is common to see novice testers creating overly complex models and setters that do not actually test the code. They might verify that the simulated code is correct, or that the simulated code does the same thing as the real code, or simply executes the code without any assertions. Such “tests” are a waste of effort, especially if they exist only to improve code coverage levels.
Worry about code coverage
Code coverage is a noble concept, but often of limited practical value. It should be useful to know how much code is being executed when a test is being run, but because it doesn’t take into account the quality of the test that is executing the code, it becomes meaningless. Code coverage is interesting when it is very high or very low. If it is very high, it indicates that too much code is probably being tested for value. Very low code coverage indicates that the code may not be tested enough. Because of this ambiguity, some people don’t know whether a single piece of code should be tested or not. I clarify this with a simple question: Does the code contain significant complexity? If yes, then you need some testing. If not, you don’t need to. Testing property accessors is a waste of time. If they fail, there is something more fundamental wrong with your code architecture than the code you are writing. If you know everything immediately without looking at a piece of code, it’s not important. This applies not only to the code, but also to the code you write. If we revisit the code at any point, it needs to be tested. If bugs are found in existing code, that area of code has not been adequately tested for its complexity.
9. Focus on one type of testing
Once you start testing, it’s easy to get stuck with just one style of testing. This is a mistake. With just one type of test, you can’t fully test all parts of the system. You need unit tests to confirm that the various components of your code work correctly. You need integration testing to confirm that the different components work together. You need to automate UI testing to verify that the software works as expected. Finally, you need to do manual testing for any parts and exploratory attempts that are not easy to automate.
10. Focus on short-term testing
Most of the value that comes from testing will come over time. Tests should not only exist to verify that things are written correctly, but should continue to function over time and make other changes to the code base. If there are regression errors or new exceptions, then tests should be run repeatedly to catch problems early, which means that errors and exceptions can be fixed faster, cheaper, and more easily. Tests that can be performed automatically and quickly without change (human error) are why coded tests are so valuable.
If none of the above is your case, congratulations! Continue to develop robust and valuable software. If any of this is happening to you, it’s time to make some changes.
Write at the end:
Long road, you wish a person alone, endure loneliness and loneliness, bear the physical and physical press, only sweat dissolved in tears, but the pace never stop. Good, even if not the laurel crown, can insist on you, will win the final applause.
The sky is always blue, sometimes covered by clouds, but the sky is always blue, and those clouds will float away one day. So we have to persevere.
So friends if tired to temporarily stop down, take a breath, rest for a moment, but don’t forget after a moment of rest, back up your bags, continue to move, I believe that if you do not forget your original intention, you will eventually reach the big place you want to reach, and finally open a flower of their own.