Introduction to JUnit

Introduction to JUnit

• 1.
  Introduction To JUnit ByDevvrat Shukla
• 2.
  Things to learn “steppingstones”
• 3.
  1. Unit Testing 2.Test Phases 3. Test Fixture 4. Junit Introduction 5. Junit Features 6. Annotations 7. Assert Statements 8. Few Best Practice
• 4.
  Unit Testing “helps youhunt down the bugs before they mature”
• 5.
  • Unit testingis a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. • Unit testing increases confidence in changing/maintaining code. • Every time any code is changed, the likelihood of any defects due to the change being promptly caught is very high. • A unit test is a piece of code written by a developer to test a unit. e.g. a method or a class, (local tests). • The percentage of code which is tested by unit tests is typically called test coverage.
• 6.
  Test Phases “four phasesin the life of a unit test”
• 7.
  Set up Exercise Verify Tear down •Setting up the test fixture. • Interact with the system under test. • Determine whether the expected outcome has been obtained • Tear down the test fixture to return to the original state.
• 8.
  Test Fixture “setting thestage to perform unit testing”
• 9.
  • In SoftwareTesting, a test fixture is a fixed state of the software under test used as a baseline for running tests; also known as the test context. It may also refer to the actions performed in order to bring the system into such a state. • Examples of fixtures: • Loading a database with a specific, known set of data • Erasing a hard disk and installing a known clean operating system installation • Copying a specific known set of files • Preparation of input data and set-up/creation of fake or mock objects
• 10.
  JUnit “first testing thencoding”
• 11.
  • Junit isa unit testing framework for the Java Programming Language. • JUnit is the Java version of the xUnit architecture for unit- and regression-testing frameworks. • Junit is a standard tool for test driven development(TDD) in Java. • Junit comes pre-bundled with several Java IDEs (Eclipse, BlueJ, Jbuilder, etc). • JUnit uses Java’s reflection capabilities (Java programs can examine their own code) • Beck and Gamma (of design patterns Gang of Four) developed JUnit on a flight from Zurich to Washington, D.C.
• 12.
  features “yes, Its possible!”
• 13.
  • Provides Fixturesto set fixed state of the software under test to be used as a baseline for running tests • Provides Annotation to identify the test methods. • Provides Assertions for testing expected results. • Provides TestRunner for running tests(main()). • Provides TestSuite for organizing and running groups of tests • Junit shows test progress in a bar that is green if test is going fine and it turns red when a test fails.
• 14.
  @Annotations “tell JUnit howto deal with the method at hand”
• 15.
  Annotation @Test public void method() @Test(expected = Exception.class) @Test(timeout=100) @Before public void method() @After public void method() Description The @Test annotation identifies a method as a test method. Fails, if the method does not throw the named exception. Fails, if the method takes longer than 100 milliseconds. This method is executed before each test. It is used to can prepare the test environment (e.g. read input data, initialize the class). This method is executed after each test. It is used to cleanup the test environment (e.g. delete temporary data, restore defaults). It can also save memory by cleaning up expensive memory structures. @BeforeClass public static void method() This method is executed once, before the start of all tests. It is used to perform time intensive activities, for example to connect to a database. Methods annotated with this annotation need to be defined as static to work with JUnit. @AfterClass public static void method() This method is executed once, after all tests have been finished. It is used to perform clean-up activities, for example to disconnect from a database. Methods annotated with this annotation need to be defined as static to work with JUnit. @Ignore Ignores the test method. This is useful when the underlying code has been changed and the test case has not yet been adapted. Or if the execution time of this test is too long to be included.
• 16.
  Note: JUnit assumes thatall test methods can be executed in an arbitrary order. Therefore tests should not depend on other tests.
• 17.
  Assert Statements “compare theexpected result with the actual result”
• 18.
  • JUnit providesstatic methods in the Assert class to test for certain conditions. • These assertion methods typically start with assert and allow you to specify the error message, the expected and the actual result. • Example: @Test public void testMultiply() { MyClass tester = new MyClass(); assertEquals("10 x 5 must be 50", 50, tester.multiply(10, 5)); } • An assertion method compares the actual value returned by a test to the expected value, and throws an AssertionException if the comparison test fails.
• 19.
  Statement Parameters in []brackets are optional. Description fail(String) Lets the method fail. Might be used to check that a certain part of the code is not reached. Or to have a failing test before the test code is implemented. The String parameter is optional. assertTrue([message], boolean condition) Checks that the Boolean condition is true. assertFalse([message], boolean condition) Checks that the Boolean condition is false. assertEquals([String message], expected, actual) Tests that two values are the same. Note: for arrays the reference is checked not the content of the arrays. assertEquals([String message], expected, actual, tolerance) Test that float or double values match. The tolerance is the number of decimals which must be the same. assertNull([message], object) Checks that the object is null. assertNotNull([message], object) Checks that the object is not null. assertSame([String], expected, actual) Checks that both variables refer to the same object. assertNotSame([String], expected, actual) Checks that both variables refer to different objects.
• 20.
  Note: You should providemeaningful messages in assertions so that it is easier for the developer to identify the problem. This helps in fixing the issue, especially if someone looks at the problem, which did not write the code under test or the test code.
• 21.
  Happy Testing!