Initial Knowledge of unit test-1

The test-driven development (TDD) seems to be disconnected from the current project. As a result, the quality of the project is completed on schedule. Two, three, five people, and a few computers, need to complete the design, UI, coding, and later testing, it is impossible to achieve agile test-driven development. Therefore, we need to review and position what JUnit can bring to us.

In JUnit, assert is used to determine whether the test is successful. That is to say, after a piece of test code, an Assert equals or assert notnull is used to determine whether the test returns a green bar. It seems to be the same as the "black box" concept of software testing.

In Java EE projects, there are usually many encapsulated methods, such as try-catch code for connecting N data sources. These modules that can be independent must be stable, to provide stable support for other modules. For example, if the LDAP server crashes a few days ago, the email cannot be sent, and the try-Catch Block can only throw an exception message such as addnode-error: ldapexception, which corresponds to at least four possible types. Finally, it was associated with other modules and with the Linux Server sa. after most of the time, it was ruled out that the original connection failed... Restart the server. It has nothing to do with the code.

The following is the operation code for adding a node to LDAP (throwing a ldapexception may cause several exceptions, including server connection failure)

Public static Boolean addnode (ldapentry newentry )...{
Boolean result = false;
Ldapconnection lc = new ldapconnection ();
Try ...{
// Connect to the server
LC. Connect (ldaphost, ldapport );
// Authenticate to the server
LC. BIND (ldapversion, logindn, password. getbytes ("utf8 "));
LC. Add (newentry );
Logger. debug ("added object:" + newentry. getdn ()
+ "Successfully .");
Result = true;
// Disconnect with the server
LC. Disconnect ();
Return result;
} Catch (ldapexception e )...{
Logger. Error ("addnode-error: ldapexception ");
Return result = true? True: false;
} Catch (unsupportedencodingexception e )...{
Logger. Error ("addnode-error: unsupportedencodingexception ");
Return result;
}

 

Take out the server connection module and perform a JUnit test:

Import static org. JUnit. Assert. fail;

Import org. JUnit. test;

Import com. Novell. LDAP. ldapconnection;

Import JUnit. Framework. Assert;

Public class ldaptest ...{

Private Static final int ldapport = 389;

Private Static final int ldapversion = ldapconnection. ldap_v3;

Private Static final string ldaphost = "192.168.1.92 ";

Private Static final string logindn = "cn = root, O = CBC, c = CH ";

Private Static final string Password = "12345 ";

@ Test
Public void connectiontest ()...{
Ldapconnection lc = new ldapconnection ();

// Connect to the server
Try ...{
LC. Connect (ldaphost, ldapport );
// Authenticate to the server
LC. BIND (ldapversion, logindn, password. getbytes ("utf8 "));
// Assert. asserttrue (true );
Fail ("Connect error ");
} Catch (exception e )...{
Assert. assertnull (E );
}
}

}

The test code only contains the connection server logic and captures the root exception during the connection process. Through such a stable unit test module, I can quickly find out if an exception occurs in operations such as LDAP crud, you don't have to worry about checking for bugs caused by other code modifications.

Therefore, compile a JUnit test class for the project's cornerstones, such as a sorting algorithm, remote interface call, database connection, and where other people's services are called, this will greatly facilitate subsequent testing during expansion, and facilitate bug troubleshooting.