JUNIT

Java unit test, by Martin Nad martin_m_nad@yahoo.com

Junit

OVERVIEW

This documentation is about how you can test your java application and what you have to think about, and why you should test

Page 1

Junit

TABLE OF CONTEXT:

FORWORD

WHITE BOX TESTING

BLACK BOX TESTGING

DEFINITION OF TESTING

UNIT TEST

ROLLS

JUNIT

ADVENTAGES WITH JUNIT

PRINCIPLES OF TEST

HOW JUNIT IS WORKING

DIFFERENT KIND OF JUNIT TESTING

TEST METHODE

HOW TO USE THE TEST RUNNER

OTHER DIFFERNT KIND OF JUNIT

LIST OF DIFFERENT KIND OF SOFTWARE TESTING

MY OTHER DOCUMENTATION

Page 2

Junit

Page 3

Junit

Junit

FORWORD

One of the most important phases of software developing is testing.

We have different kind of testing, but we can group all of them in to two categories:

1. Black box testing,

2 .white box testing

Unit testing is a kind of “white-box-testing”

WHITE BOX TESTING

White box testing is about internal design and structure test and I’m goanna to discuss about it.

BLACK BOX TESTING

Page 4

Junit

Black box testing is about functional and none-functional testing.

The functional testing is about input and behaviour and output testing

None-functional testing is about reliability test , scalability and software performance.

The aim of this documentation is: how we can test our application with focusing to internally structure and JUNIT.

DEFINITION OF TESTING

It is not very simple to define what it is a testing a bout, because we have too many different kind of testing as:

We can have validating testing and verification testing,

We can have usability testing and security-testing and so on, there are more than 20 different kind of testing. We can define testing just whit respect to what we want to test.

I can very easily define as follow: Software testing helps us to find any error/bug in an application before we deliver or put it on the live-environment. The errors can be validation, verfication, security and so on.

Page 5

Junit

UNIT TEST

ROLLSWhen you want to write your Test-class you should think about that

-just have one assert per test

-just test one functionallity per test

JUNIT

Junit is a framework to write tests case and during the developing, debugging, adding features we can reuse the same test and we can add new test case of course. Junit is about internally-test or some kind of white box-testing and it can help us to find error in early stage and during developing, debugging or refactoring.

We should test our application before and after we implement any new featuer to the application.

Page 6

Junit

ADVENTAGES WITH JUNIT

Junit is a kind of white box testing, and it is just about internal structure testing.

You can find error in very early staging and during your developing phase.

It helps you to locate and find very precisely place of error and even find error and during debugging and refactoring

PRINCIPLES OF TEST

We should have a test case for every variation type of input, also not every possible instance of input.

We should test cases for combinations or permutation of all variation types of the implemented operations.

For example, if we have a string-compare function

We should test just with two different strings to check the string-compare function with two different options

1- If the string1 is equal with string2

2- If the string1 is part of string2

Page 7

Junit

It is important to know how the test should happen for example for a multiplication-operation, it is enough to test just one positive number and 0, and you shouldn’t test all positive number to each other.

And if you want to test the border on your operation you can just test with two big integer numbers together.

HOW JUNIT IS WORKING

What you have to test, can be:

requiredResult= achivedResult

Or in other form:

requiredResult.equals(achivedResult) ;

You should to know that it is not necessary to use junit for testing your structure, you can just write your own test-program and just use it.

Page 8

Junit

Example 1

• if (achivedResult == null || ! requiredResult.equals(achivedResult) ) throw new MyTestyException(“Unexcepted Result");

• With JUnit, you can code import static org.junit.Assert.*; ...

assertEquals(“Unexcepted Result", expectedResults, requiredResults);

• Every part of junit asserts method throws by java.lang.AssertionErrors if the test fails.

DIFFERENT KIND OF JUNIT TESTING

• You can find lot of various assert depend on your test, here is just a short list of the whole assert-methods:

• assertArrayEquals

• AssertEquals

• assertFalse

• assertNotNull

• assertNotSame

Page 9

Junit

• assertNull

• assertThat

• assertTrue

• Fails

You will find the whole definition of methods on

TEST METHODE

• For example if you have n-numbers of the methods, it is better you have a test-case for each of methods. Junit should test all and report if all of test passed throw or which one was failed. • Something that interesting it can one of the method, or test, cause very violet result, and in this case you can find it easily

• @org.junit.Test

public void testGetPropertyWithReplacements() {

PropertyManager propManager = new PropertyManager();

propManager.init();

String replacedString = propManager.getPropertyWithReplacements ("text.to.replace", replacements);

Page 10

Junit

assertTrue(replacedString.indexOf(replacem ents[0]) > 0);

}

• You should have some init method without any parameters. You can call it whatever, but it shouldn’t have any parameters.

• You should to remember that any test unit or methods should be single threaded and it shouldn’t depend to any other test-unit or values of static variables or instance.

• And if you want to use any instance of variables, each test-methods should

Handling throwables in test methods

@org.junit.Test

public void testGetPropertyWithReplacements() {

Try{

PropertyManager propManager = new PropertyManager(); propManager.init(); String replacedString = propManager.getPropertyWithReplacements("text.to.replace", replacements); assertTrue(replacedString.indexOf(replacements[0]) > 0); }catch(Exception e){ AssertionError ae = new AssertionError( “test Application failed to confirm the properties");

ae.initCause(e); throw ae;

} }

Page 11

Junit

DIFFERENCES BETWEEN JUNIT FAILURES AND ERRORS

• A failure is a test-process that your code has failed by using a certain process for the aim of the method • And a error, is get unexpected problem

EXAMPLE 3

Import java.lang.*;

Public class StringTest extend AbstractStringTest{

@Test Void testString(){...}

@Test Void testString1(){...}

@Before Void testEqual(){...}

@Before Void testEqual_1(){...}

@After Void testContians(){}

@After Void testContians1(){} }

• The anotation @befor and @after specify the methods order to execute

• The order of this test is:

• testEqual()

Page 12

Junit

• testEqual_1()

• ........

• testString()

• testString1()

• .........

• Testcontains()

• TestContains1()

• But the order in the those three groups can changes

• As I saild before the test-methods should be independent to each other.

HOW TO USE THE TEST RUNNER

• From command line you can very easily use this command •

Java –cp path_to_thte libjunit.jar org.junit.runner.JUnitCore com.acme.LoadTester yourpackege.yourclass

• From main:

• public static void main(

String args[]) {

org.junit.runner.JUnitCore.main(You rTester.class.getName());

Page 13

Junit

}

HOW USE JUNIT WITH ANT

• And this an example of ant-script to running Junit-test

<project default="all">

<property name="tst-dir" location="test" />

<property name="TEST" value="true" />

<path id="classpath.base">

</path>

<path id="classpath.test">

<pathelement location="/Projects/Java/Lib/junit.jar" />

<pathelement location="${tst-dir}" />

<path refid="classpath.base" />

</path>

<target name="compile-test">

<javac srcdir="${tst-dir}" verbose="${TEST}" >

<classpath refid="classpath.test"/>

</javac>

</target>

Page 14

Junit

<target name="clean-compile-test">

<delete verbose="${TEST}">

<fileset dir="${tst-dir}" includes="**/*.class" />

</delete>

</target>

<target name="test" depends="compile-test">

<junit>

<classpath refid="classpath.test" />

<formatter type="brief" usefile="false" />

<test name="TestExample" />

</junit>

</target>

OTHER DIFFERNT KIND OF UNIT TEST

• Easy moch: http://easymock.org/

• Power moch: http://code.google.com/p/powermock/

• Mockito: http://code.google.com/p/mockito/

• Jmock: http://jmock.org/

Page 15

Junit

• Fest mocks http://fest.easytesting.org/mocks/wiki/pm

LIST OF DIFFERENT KIND OF SOFTWARE TESTING

Black box testing - Internal system design is not considered in this type of testing. Tests are based on requirements and functionality.

White box testing - This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.

Unit testing - Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

Incremental integration testing - Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers.

Integration testing - Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing - This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.

System testing - Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.

End-to-end testing - Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a

Page 16

Junit

database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

Regression testing - Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.

Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.

Load testing - Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

Stress testing - System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.

Performance testing - Term often used interchangeably with ’stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.

Usability testing - User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

Recovery testing - Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Security testing - Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks or not.

Page 17

Junit

Compatibility testing - Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.

Comparison testing - Comparison of product strengths and weaknesses with previous versions or other similar products.

Alpha testing - In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.

Beta testing - Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

Get from http://www.softwaretestinghelp.com/types-of-software-testing/

Internationalization Testing

API Testing

Additional site for testing: http://www.testinggeek.com/index.php/testing-types

Some ExamplesListing 1

import junit.framework.TestCase;import org.junit.Test;import org.junit.Before;

import dk.unwire.apps.tellafriend.tools.Msisdn;

public class MsisdenTest extends TestCase {

@Beforepublic void init() {

this.msisdn = new Msisdn();}

@Testpublic void msisdnStringRightDigitTest() {

this.msisdn = new Msisdn();assertEquals(true, this.msisdn.IsRightString("123467"));

Page 18

Junit

}

public void msisdnStringWrongDigitTest() {assertNotSame(true, this.msisdn.IsRightString("123467m"));

}

private Msisdn msisdn;

}

Listing 2

import org.junit.*;import static org.junit.Assert.*;import java.util.*;

public class SimpleTest {

private Collection<String> collection;

@BeforeClass public static void oneTimeSetUp() { // one-time initialization code }

@AfterClass public static void oneTimeTearDown() { // one-time cleanup code }

@Before public void setUp() { collection = new ArrayList<String>(); }

@After public void tearDown() { collection.clear(); }

@Test public void testEmptyCollection() { assertTrue(collection.isEmpty()); }

@Test public void testOneItemCollection() { collection.add("itemA"); assertEquals(1, collection.size()); }

Page 19

Junit

}

Listing 3import java.util.regex.Matcher;import java.util.regex.Pattern;

public class RegularTestMain {

/** * @param args */public static void main(String[] args) {

Pattern p = Pattern.compile("[0-9]*"); Matcher m = p.matcher("121212");System.out.println( m.matches()+" p3");

}

}

FEEDBACK• Please send your feedback/question to martin_m_nad@yahoo.com

DONATION

If you like this documentation and it was helpful you can just donate 7$ by using this

Page 20

Junit

https://www.paypal.com/cgi-bin/webscr?cmd=_s-

xclick&hosted_button_id=5814019 or use this to put any amont you like to donatehttps://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=5813954 and if it doesn’t work copy the link and put it on your browser.if it doesn’t work copy the link and put it on your browser.

Page 21

Junit

My other documentation

Properties in Java and Spring by Martin Nad

Spring and Cxf by Example

Jboss and Perm Gen Error

Using Ftp Service With Spring

JunIt

How to use Maven

ReFactoring

Maven and Custome Archetype

How to Write Effective Code

How to use caching system in java

Page 22