I blog about debugging, development using .net, C#, SQL, and other Microsoft technologies.
Disclaimer: All posts are provided "AS IS" with no warranties, confering no rights, and expressing only my personal opinion, not Microsoft's.
Just like design patterns, the use of test patterns will make your life easier. A lot of the common testing methods can be reused. Along with the benefits of reuse, using patterns makes it easier to explain to others what you are going to do in a word or a two instead of telling the whole story. Moreover, test patterns provide guidelines for solving common test design problems and define measurable actionable methods of testing. Test patterns have certain attributes that shape the pattern. It has an easy to remember name, which people agree upon and use to refer to the same test method. The pattern should be used to solve a certain problem, the same problem can be addressed by multiple problems, however, a pattern should tackle one problem and focus on its solution. Analysis of the problem addressed by the pattern is very important as it shows the various dimensions of the problem and why this pattern is the best solution for it. Test patterns are basically design patterns to solve testing problems; it has to have an algorithm or a sequence that forms the solution and shows how the test cases will be implemented. When test cases following this pattern are run, they will yield results that should be expected by the oracle of the pattern. And to make it easier for others who are going to use the pattern, it should list some examples, and how it relates to other patterns; a pattern doesn’t have to have related patterns though. To be explicit about when the pattern should be used and when it’s not suitable for the task at hand, limitations and restrictions should be listed too. Overall, these are the key attributes of a pattern, but there might be other attributes that can be added to specific patterns.
Using patterns is recommended, because it’s conventional and standardized, but sometimes we face unusual problems that require unusual solutions. If a solution is so unique, specific, and is not likely to be reused, it may not be a good candidate for a test pattern. This doesn’t mean that patterns discourage innovation in problem solving, on the contrary, a pattern can get replaced by a better one solving the same problem. So, sharing the better solution among teams, or better among a community members is a good opportunity to create a new pattern.
For more info: http://www.hwtsam.com and http://msdn.microsoft.com/en-us/library/cc514239.aspx
PingBack from http://microsoft-sharepoint.simplynetdev.com/test-patterns/
I agree that if a problem has already been solved, then one should use the technique that has been proven to work. However, today we see many people trying to use a patterns (mainly design patterns) where they do not fit. For example, some senior Java programmers (collegues) will not think your software is good enough unless you employ every single pattern whether or not it makes sense. I dislike that way of thinking, where people think of the pattern before the problem, we should not put the horse behind the carriage, but on the other hand, look at the problem and try to find a sollution which best fits the problem. Slightly off topic here :), but when looking at test patterns many people use the one hammer fits all approach. Many projects rely heavily on unit testing and forget other important testing strategies, or even try to think of what fits best.
Nice post Geish!