--------------------
Preface
--------------------
This article introduces a novel test idea and creates a prototype system to demonstrate its effect.
This technology will be part of the test drive Framework 2.0 (Testdriven 2.0 ).
The purpose of test drive 2.0 is:Communication between codes makes changes easier.
--------------------
Test category and the object discussed in this article Catalog
--------------------
There are many types of tests, each of which needs to be addressed by specific technologies, such:
1. Winform Interface Test: Generally, Win32 interfaces such as hooks are used to capture user operations and simulate playback for testing (this technology is not covered)
2. Web Interface Test: JS is usually used to embed the test page, and user operations are also simulated; or internal functions such as the IE kernel are called to implement user operations (this technology is not discussed)
3. Http testing of the Web: it is difficult to implement in. net 2.0. In Versions later than 3.0, Microsoft restructured the HttpContext, which makes the test a little simpler. (This technology is not discussed)
4. Class Library and code testing: this is the end point of my discussion, including various frameworks and Logic Applications. The existing technologies are mainly UNit/Testdriven.net/Mock. They seem to have solved some problems. But...
Therefore, this article will focus on4th tests(Class Library and code testing)Is also the most common test for discussion.
---------------------
Existing problems: Problem
---------------------
A large part of the current test is regression. Developers dream of writing Automatic Test code. If there are changes in the future, they will know whether the previous functions are damaged and whether bugs have occurred through regression. To this goal, many testing tools were created. But in my opinion, they just jumped from one small pitfall to another. (That is, what I said earlier has fallen into the self-built pit)
First, whether the test results are accurate depends on whether the test data is fully accurate. Then there is a human bug in writing test data.
Second, the test code is closely related to the Business Code. Once the Business Code is modified, the test code is always totally negative. This leads to a conflict: if the test code is sloppy, it will basically not be used in the future. If the test code is well written, the previous work will be wasted once it is modified.
So what we really expect is:Ability to automatically analyze business code and automatically write test codeInstead of writing. This goal is still very difficult to achieve (Microsoft has introduced a lot of Code Gen and other technologies in VS2010, ..)
However, this is not the case. I will try to take a small step below.
---------------------
Principle Analysis
---------------------
To make the test automatic, you must first abstract the test process and then break it down one by one. After my analysis, a piece of test code mainly includes three aspects:
1. Test Data generation.
It directly determines whether the test code is valid. Therefore, it requires comprehensive, accurate, and precise business logic binding. There is no better idea for this part of work.
2. Call the corresponding method.
This is very simple. It is to call a method to pass in the test data. There is no need for optimization.
3. Check whether the test results meet expectations.
This part was previously written into this very boring Assert. IsEqual and so on. It is boring and time-consuming. I have found the space for improvement.
The test results are nothing more than strings and objects. Is the ValueType/class of c. If it is an object, it must also be some properties of the object ). And the data can beSerialization and deserializationOf!
Therefore, this process can be completely replaced by machines, making the test code more flexible and reducing the workload by 50% immediately! Now I will show you the current prototype system effect.
---------------------
ProtoType
---------------------
The first is a piece of test code.
Public void test00001 ()
{
Object pojo = CreatePojo ();
Assert. SaveOrVerify ("test000 create pojo", pojo );
}
The purpose of this Code is to test whether the generated pojo object meets expectations. A Pojo object may be an instance of the following interface:
Code Interface IinterfaceWithAllCollection
{
Byte [] Image {get; set ;}
String Name {get; set ;}
Double keys {get; set ;}
Int Age {get; set ;}
IinterfaceWithAllCollection [] pojos {get; set ;}
List <IinterfaceWithAllCollection> pojos2 {get; set ;}
ObjectWithValue objPojo {get; set ;}
ObjectWithValue [] objPojos {get; set ;}
List <ObjectWithValue> objPojos2 {get; set ;}
}
In the past, we had to expand this object, get every attribute, and then perform Assert.Now I only need one sentence to complete the test result verification.:
Assert. SaveOrVerify ("test000 create pojo", pojo );
Do you feel the charm and surprise?
After this statement is called, the framework first searches for the result data stored on the disk, which is generally an xml file. The data is essentially the serialization value of the expected result. Then compare them one by one.
So you must be curious, where do these expectations come from? The answer is that the Code itself is generated. When there is no expected value for the first execution, the framework will give a warning, and then the current data will last to the disk. For example:
Code ------ Test started: Assembly: Pixysoft. Framework. Configurations. dll ------
WARNING: expected valueDoNot existed. createNewOneForTest000 create pojo
Verifying IinterfaceWithAllCollection. Image.
TRUE: expected = % 01, actual = % 01
Verifying IinterfaceWithAllCollection. Name.
TRUE: expected = hello, actual = hello
Verifying IinterfaceWithAllCollection. mismatch.
..... Omitted
At this time, I call a configuration interface to view the value generated for the first time and change it to the expected value:
Such a serialized structure can be displayed in a tree structure. Now we only need to check whether the first running result is correct and adjust ExpectedValue. In this way, the test code can be repeatedly called forever.
----------------------
Summary
----------------------
Because it is a prototype system, the first release cannot be issued yet, but it can be completed soon. The main reason is that the code I wrote is as bad as the code I wrote, and it needs to be optimized.
When release is released, all code will adopt an open-source strategy. It is just a new open-source strategy.
If you are in urgent need, we can discuss and discuss with each other. I hope you will provide more ideas and more requirements as you expect. Thank you!