Enhance the En Garde! Remember that your customers have a different idea of your products. They will have never been able to install it at least in a group that you have never thought - or at least there is no test. They will use it with methods you have never thought and configure it with you unexpected methods. The following list helps you guarantee that they will not be angry:
Verify all the integrity of all received parameters (Consider if you expect an array to pass is a null, but what happens when you have not checked this possibility before the index array). Consider the possible error conditions and increase the code to handle each case (you want the code to deal with the error condition instead of blocking it). For those unpredictable error conditions, add a general "capture all" error handler. Use constants when appropriate and place. Add tracks and logs in each of the code. If your product will be translated into another language, then ensure that your code can "support" it. Even if this happens, the opportunity is small, but it is always better in advance. Modifying the code to make it easier to produce defects. Below is a few questions you have to consider:
Do you have any hard-coded string? Do you have different dates / time correctly? Different currencies? Also, use a lot of assertions in your code. Give your code plus a full annotation. In short, do you remember the idea when preparing that method? What do you want to modify your code after one year? This may be the most important in all the recommendations we propose. Unit test (defensive test technology) In this article, the unit tests we said is that the developers have correctly compiled their own code, all tests and analysis before they are given to the functional test team. As we mentioned in this is just a test, it is important to think about unit testing and thinking like a tester during testing (ie, you must think of bad things, passionate and like prank) is very important. Here is a few things to remember when testing in units. The first type of static code analysis tool is also the easiest analysis of the code to let others do it for you - or like this, let other tools. There are some different static code analysis tools available, from a comprehensive tool - some development organizations actually add such tools in their "compiled" environment (this is needed) - to other available free from Internet Uploaded tools. Discover the defect When you are ready to run the code and check the defect, you should remember to think about it. These defects are generated by the code you create or by your ignored. Here are some tips that help you find the defects in your code:
Try to create all the wrong conditions you think and check all the error messages that can appear. Try to use the code path interact with other components or procedures. If other programs or components do not exist, write some scaffolding code to make you try API or populate shared memory, share queues, and so on. And let your function test team can use this scaffolding code so they can join it into their weapon library. For each of the input fields in the GUI, there are many different combinations below (considering automation):
Unacceptable characters (control characters, non-print characters, etc.). Excessive characters. Too little characters. Negative numbers (especially when you only expect positive numbers). Excessive and / or too small. Cut and paste data and text to the input field, especially when you write code restrictions, you can type contents of the field. A combination of text and numbers. Full capital letter and full lowercase letters. Create "Pressure Conditions" for your code, such as a large number of activities, slow-connected networks, and all you think of to push the code to the limit condition. Repeatedly the same steps, then:
Check the unforeseen memory loss conditions. Check what happens when memory is light. Trying to create a cache overflow, a queue, unavailable cache, and other "not working correctly". For arguments and cache, try to increase N data items to argments (or caches), then try to delete N 1 item. About time considering? What happens if "b" occurs before operating "A"? Even if you think it won't happen - Can you make it happen? If so, you can bet your customers will make it happen. It is best to find it now, not higher fixation costs, and I will do it again after the customer's quality is bad. Scaffolding code We discussed scaffolding code in the previous discovery defect. If it is created for your own usage, you must give it to the verification engineer. The scaffolding code that may be provided allows them to quickly test your code, or at least make them better understand what can be expected when other components are present. If your product has a protective security function, you must test them. Providing scaffolding code that can create the situation you want to prevent: You must be able to create the situation that the system is trying to prevent. Another simple example of scaffolding code is the code to provide a queue. If your product uses a queue, imagine if there is a tool that can be added or deleted from the queue from the queue, it will be more convenient. The source code-level debugger uses the source code-level debugger to be a key way for thorough and successful unit tests. Developers should live with their debugging procedures. Unfortunately, the full understanding of the source code-level debugging procedures is a pendant approach, although the benefits of these debuggers far exceed any learning curve. In short, we strongly encourage you to fully learn a debugger. Below is a way to use the source code-level debugger to unit test of the code. You can: Manipulate data in operation, for example, set interrupt points when entering code, and then reset the passing parameter value to check if the code can correctly handle (now) invalid parameters. In this way, the use of the debugger does not need to make the error condition truly. Set breakpoints, then "single step" through code, so you can see what you do every line of code. Set "Monitoring (Watch)" for variables. Force the error code path. Observe the call stack to check which one routine calls your code. "Capture" when the error occurs. Perform a boundary check. Know your verification engineer verification engineer is a good source of testing knowledge. They can give you what to test and help you understand what you can join in your code to help them test (such as code hook). In addition, you can show them how to use your scaffolding code. They will also be very interested in understanding what you think is automated in the test - if you do more than once, then they will. Start test! It is time for small tests. Let us see if you are interested. Question You want to check if the value of an integer is 5. Usually, write code like this:
IF (i == 5) THEN
{
//
// do something ...
//
}
However, if you perform "finger check" for the code, and write the code what will happen below?
IF (i = 5) THEN
{
//
// do something ...
//
}
This mistake is a defect, but only can capture it at runtime - it may require considerable debugging efforts to find it. The compiler will easily let your code, so how to prevent this error from happening? The answer actually has two answers: You can use a static code analysis tool described above, and hope that it has sufficient robustness to capture this error, or exchange the operands to make the constant on the left:
IF (5 == i) THEN
{
//
// do something ... //
}
Because this method guarantees that you can capture problems immediately when compiling code, it is the preferred technology. Although it looks some stupid, the code can compile and run well. However, when you "Finger Check" code, you can immediately see the benefits:
IF (5 = i) THEN
{
//
// do something ...
//
}
However, the compiler does not like this because 5 cannot be assigned another value. This is what we said earlier, you should see the compiler as the meaning of your friend. You can also use this trick when checking the Null pointer. Look at the following code:
IF (returbtring == null)
{
//
// do something ...
//
}
What happens if you accidentally "mistaken" in this way?
if (returnstring = null)
{
//
// do something ...
//
}
You may not get the desired results. And use the following method you will get the same "compiler protection" we just described:
IF (null == returbtring)
{
//
// do something ...
//
}
Conclusion To maintain your concise summary, we have done a quite concise summary: either do now, or have more expensive costs. In other words, the more time you spend on the early test and prevention code defects in the development cycle, the more time and money you have saved later. This is the meaning of defensive coding. It is so simple.
