The document provides information about JUnit, a unit testing framework for Java. It discusses what JUnit is, why it is used, its history and basic annotations. Key points include: - JUnit serves as a foundation for launching testing frameworks on the JVM and defines the TestEngine API. It provides a Console Launcher and supports popular IDEs and build tools. - JUnit allows developers to write automated tests to validate code works as intended before deploying. This reduces bugs and tracks changes made by others. - Basic annotations in JUnit identify test methods and classes, allow ignoring tests, and specify expected exceptions. - JUnit advocates writing isolated, fast, and independent unit tests through

1. 2/1/2021
Suraj Savaratkar

2. What is
Junit?
The JUnit Platform serves as a foundation for
launching testing frameworks on the JVM. It
also defines the TestEngine API for developing
a testing framework that runs on the
platform. Furthermore, the platform provides
a Console Launcher to launch the platform
from the command line and a JUnit 4 based
Runner for running any TestEngine on the
platform in a JUnit 4 based environment.
First-class support for the JUnit Platform also
exists in popular IDEs (see IntelliJ IDEA,
Eclipse, NetBeans, and Visual Studio Code)
and build tools (see Gradle, Maven, and Ant).
01-02-2021

3. Why Junit?
01-02-2021
Developer are write the code for business
functionality and the code will go on production. If
any mishap happens whole functionality will
collapse because of functional testing have not
write. To cover any sudden mishaps we should write
a Junit testing according to, what functionality have
implemented. The Junit framework make it
happens. Each Junit test case is independent and
can write multiple cases for each scenario. In
addition, tests are running concurrently. The
simplicity of Junit make it possible for the software
developer to easily correct bugs as they found. It
will also track the status of the code that was wrote
by somebody else and that tests are not affect by
newly added line. It also reduce the bugs in
delivered code.
• To isolate the each part of the application
• Show each isolated part is correct

4. 2/1/2021

5. Junit History
01-02-2021

6. Basic Annotations
@BeforeClass – Run once before any of the test methods in the class, public static void
@AfterClass – Run once after all the tests in the class have been run, public static void
@Before – Run before @Test, public void
@After – Run after @Test, public void
@Test – This is the test method to run, public void
@Test (expected = Exception.class) – specify the what type exception should catch this test case, public void
@Ignore – This case is not execute it will ignored by TestEngine, public void
@RunWith - Tells JUnit to run using Spring’s testing support, Class level
@PrepareForTest - This annotation tells PowerMock to prepare certain classes for testing, Class level
@PrepareForTest(value = ClazzName.class) - This annotation tells PowerMock to prepare all tests from given
class for testing, Class level
01-02-2021

7. Basic Annotations (Cont.)
@Mock - Is used for mock creation. It makes the test class more readable.
@Spy - Is used to create a spy instance. We can use it instead spy(Object) method.
@InjectMocks - Is used to instantiate the tested object automatically and inject all the @Mock or
@Spy annotated field dependencies into it (if applicable).
@Captor - Is used to create an argument captor
01-02-2021

8. Few Basic Assert method
• assertArrayEquals (byte[] expecteds, byte[] actuals)
• assertArrayEquals(char[] expecteds, char[] actuals)
• assertEquals(long expected, long actual)
• assertEquals(java.lang.Object expected, java.lang.Object actual)
• assertFalse(boolean condition) assertFalse(java.lang.String message, boolean condition)
• fail(java.lang.String message)
• assertTrue(boolean condition)
• assertSame(java.lang.Object expected, java.lang.Object actual)
01-02-2021

9. Advantages
• Simple framework for writing automated, self-verifying tests in Java
• Support for test assertion
• Test suite development
• No state sharing
• Immediate test reporting
• Annotations to identify test methods
• It does not required to access the network
• It does not required to hit the database
• Does not use file system
01-02-2021

10. Advantages (Cont.)
• Reduce the number of bugs once deployed
01-02-2021

11. Lifecycle of the Test class
01-02-2021

12. Testing hierarchy
01-02-2021

13. Unit testing best practices
• 5 step
• Execution time – Be fast
• Consistent
• Atomic
• Single responsibility
• Test isolation
• Environment isolation
• Class isolation
• Fully automated
• Self-descriptive
• No conditional logic
• No loop
• No Exception catching
• Assertions
• Informative assertion messages
• No test logic in production code
• Separation per business modules
• Separation per type
01-02-2021

14. 5 steps
• Setup
• Prepare an input
• Call a method
• Check output
• Tear down
01-02-2021

15. Execution time – Be fast
Frequent execution
• Several time per day – [Test After development]
• Several time per Hour –[Test driven development]
• Every few minutes – [IDE – Execution after save]
Execution in group
• 10 tests – execution time x 10
• 100 tests – execution time x 100
01-02-2021

16. Execution time – Be fast (Cont.)
What are good numbers?
Expected average execution time in junit testing:
• Single test – <200ms
• Small suite – <10s
• All test suites – <10 min
01-02-2021

17. Consistent
Multiple invocations of the test should consistently return true or false, provided no changes was
made on code.
How to deal with this?
• Mocks
• Dependency injection
01-02-2021

18. Automatic
• Only two possible results: true or false
• No partially success tests
• A test fails – The whole suite fails
01-02-2021

19. Single responsibilities
Test Behaviour, not methods:
• One method, multiple behaviours  Multiple tests
01-02-2021

20. Single responsibilities (Cont.)
• One behaviour, multiple methods  One Test
• A method calls private and protected methods
• A method calls very simple public methods
• (Specially, getters, setters, values objects simple constructor)
01-02-2021

21. Test isolation
Test should be independent from one another.
Different execution order - the same results
No state sharing
Instance variables:
• Junit - separated
• TestNG - shared
01-02-2021

22. Environment isolation
Unit test should be isolated from any environmental influence
• Database access
• Web services call
• JDNI lookup
• Environmental variables
• Property files
• System data and time
01-02-2021

23. Environment isolation (Cont.)
If class heavily uses the environment:
01-02-2021

24. Environment isolation (Cont.)
Under this unit testing is does not work:
01-02-2021

25. Environment isolation (Cont.)
The solution is mock:
01-02-2021

26. Environment isolation (Cont.)
Java mocking libraries:
• Easy mock
• Jmock
• Mockito
• Powermockito
01-02-2021

27. Classes isolation
01-02-2021

28. Classes isolation (Cont.)
Let see the example:
Steps 0: The class under test has no dependency
Step 1: The class is depends on some other
classes
01-02-2021

29. Classes isolation (Cont.)
Step 2: Dependencies of dependencies • Step 3: Dependencies of dependencies of
dependencies
01-02-2021

30. Classes isolation (Cont.)
• Step 4,5,6 Conclusion: Mocking the environment is not
enough
01-02-2021

31. Classes isolation (Cont.)
Solution: Mock the dependency Can be hard if code is not testable:
How to write testable code
• Do not call constructors inside a method.
Use factories of dependency injection
• Use interfaces
01-02-2021

32. Fully Automated
No manual steps involved into testing
• Automated tests execution
• Automated result gathering
• Automated decision making (success or failure)
• Automated result distribution
o Email
o System tray icon
o Dashboard web page
o IDE integration
01-02-2021

33. Self-descriptive
Unit test = development level documentation
Unit test = method specification which is always
up to date
Unit test must be easy to read and understand
• Variable names
• Method names Self-descriptive
• Class names
• No conditional logic
• No loops
01-02-2021

34. No conditional logic
Currently written test contains no “if” or
“switch” statements
No Uncertainty:
All inputs values should be known
Method behaviour should be predictable
Expected output should be strict
One test, multiple conditions
01-02-2021

35. No loops
Case 1: Hundreds of repetition
If some logic in a test has to be repeated hundreds of times, it probably means that the test is too
complicated and should be simplified.
Case 2: A few repetition
Repeating thing several times is OK, but it is better to type a code explicitly without loop. You can
extract the code which needs to be repeated into method and invoke it a few times in a row.
Case 3: Unknown number of repetitions
If you don’t know how many times you want to repeats the code and it makes you difficult to avoid
loops, it’s very likely that your test is incorrect rather focus on specifying more strict input data.
01-02-2021

36. No exception catching
Catch an exception only if its expected
Catch only expected type of an exception
Catch expected exception and call “fail”
method
Let other exceptions go uncatched
Catching expected exception
01-02-2021

37. Assertions
Use various types of assertions provided by a testing framework
Create your own assertions to check more complicated, repetitive conditions
Reuse your assertions methods
Loop inside assertions can be a good practice
01-02-2021

38. Informative assertion messages
By reading an assertion only, one should be able to recognize the problem.
It’s a good practice to include business logic information into messages
Assertion messages:
Improve documentation of the code
Inform about the problem in case of test failure
01-02-2021

39. No test logic in production code
Separate unit tests and production code
Don’t create methods/fields used only by unit tests
Use “dependency Injection”
01-02-2021

40. Separation per business module
Create suites of tests per business modules
Use hierarchical approach
Decrease the execution time of suites by splitting then into smaller ones (Per sub-module)
Small suites can be executed more frequently
01-02-2021

41. Separation per type
Keep unit tests separated from integration tests
Different purpose of execution
Different frequency of execution
Different time of execution
Different action in case of failure
01-02-2021

42. Write test case for controller layer
Annotate the class:
Import common static imports
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.assertEquals;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.delete;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.post;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.put;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.jsonPath;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;
01-02-2021

43. Write test case for controller layer (Cont.)
Mock the beans
Prepare the input:
Mock the method:
01-02-2021

44. Write test case for controller layer (Cont.)
Call a api:
TearDown
01-02-2021

45. Write test case
Annotated class
Mock the beans
01-02-2021

46. Write test case (Cont.)
Mock the methods
Call a method
Assertion
01-02-2021

47. Hierarchy of package structure
01-02-2021

48. Thanks