The relationship between testability and good design _ test Cases

The problems found in the good unit test cases expose the flaws in the design and code.
During the recent period, the introduction of unit testing has increased dramatically. In the late 90 and early 2000, this habit seemed to be very feeble. Often, people adopt a new technology, and back then, institutions are moving from structured design approaches to object-oriented design, focusing all their attention on vital rights while discarding routines that don't seem to fit neatly into the new vision of the world. Therefore, unit tests are ignored.
But, very rarely, but to say what we have learned from the last 10 years is that we have learned that unit testing is a very important subject. Testing helps us write code better, forming a regression base that makes refactoring and making it easier to add features. Someone discusses a very subtle effect of unit testing. There seems to be some very close connection between the testability of the unit level and the good design. It is almost universally accepted that the difficult code must have a design problem. When you fix a design problem, the test becomes simple.
Let's take a look at an example.

In Figure 1, we have a class that looks good in design. There is a public method, evaluate (), which is the point of contact between the user and the class. It passes its work to a series of private methods. Obviously, there is nothing wrong with such a class, Ruleevaluator does what we want it to do. Now, how do we write unit test cases for this class? We should be able to, for example, use multiple variables to invoke the evaluate () method and then examine the results. But what if we want to test the Getnexttoken () method.
.....
See the full text please click to download: http://www.51testing.com/html/42/n-863942.html
This example may annoy you. You can argue that it is meaningless to pull them into their class without reusing the code in the Getnexttoken () or Hasmoretokens () method, because it adds to the number of classes in a meaningless way. But doing this really makes the code more modular. We can reuse the Ruletokenizer method at some point in the future. At the very least, it is now clear that we should make a change in where to mark the functional code. Our code is less relevant, and it's easier to change one without affecting the other.
If this is the only example of a signal that the low testability is a poor design, it will only be considered a fluke, but it is not. In general, the pain of unit testing is an indication of a local error. Sometimes the pain is obvious. For example, if you have to create a lot of objects to get to the object you want to test, this is often an expression of excessive coupling. Other situations are more subtle. Let's take a closer look at some examples.
.....
See the full text please click to download: http://www.51testing.com/html/42/n-863942.html
This article is included in the "51 Test World" electronic magazine 34th.
Copyright Notice: This article is from 51Testing Software test network Electronic magazine, "51 Test World" 34th phase. 51Testing Software test Network and related content providers have all the copyrights of 51testing.com content, without express written permission, no one or unit shall copy, reprint or mirror the contents of this website, otherwise it will be held liable.