Java Unit Test - JUnit

Unit tests: testing individual methods (low-level)
Integration tests: interaction with the database or making sure that microservices work together as expected
Functional tests: only verify the output of an action and do not check the intermediate states
End-to-end tests: more complex scenarios verifying email notifications, online payments (high-level)
Acceptance testing: replicating user behaviors (entire application)
Performance testing: behaviors of the system when it is under significant load
Smoke testing: after a deployment to make sure that they application is running properly
...
...
...

TestNG: Unit testing
Cucumber: Integration testing
Robot Framework: Acceptance testing
Mockito: PowerMock/JMock ...
Selenium: Acceptance testing

"Test" suffix at the end of test classes names.
a test name should explain what the test does
Given[ExplainYourInput]When[WhatIsDone]Then[ExpectedResult]
You should use the "Test" suffix for test classes. The Maven automatically includes such classes in its test scope

JUnit assumes that all test methods can be executed in an arbitrary order.
- test code should not assume any order,
- tests should not depend on other tests.
annotation.

@Test : Declares a test method @Test(timeout=2000)
@BeforeClass - @BeforeAll : method will be executed before all test methods
@AfterClass - @AfterAll : method will be executed after all test methods
@Before - @BeforeEach : method will be executed before each test method
@After- @AfterEach : method will be executed after each test method
@Ignore- @Disable : Disable a test method or a test class
@Category- @Tag : Declare tags for filtering tests

fail : Let the method fail.
assertTrue : (message , condition) Checks that the boolean condition is true.
assertFalse : (message , condition) Checks that the boolean condition is false.
assertEquals : (message , expected, actual) Tests that two values are the same.
assertEquals : (message , expected, actual , tolerance) float or double values match
assertNull : (message , object) Checks that the object is null.
assertNotNull
assertSame : (message , expected, actual) Checks that both variables refer to the same
object.assertNotSame :
assertThat : (actual, matcher) Checks that with CoreMatchers. *****

any(): Matches any object passed to it.
is(): A matcher that checks if the given objects are equal.
describeAs(): adds a description to the matcher
allOf(): Takes an array of matchers and must all match the expected object.
anyOf(): Takes an array of matcher and must match at least one of the matchers must report that it matches the target object.
not(): Check if the object negates what was passed.
equalTo(): Equality check.
instanceOf(): Check if an object is an instance of a given/expected object.
notNullValue(): Check if the passed value is not null
sameInstance(): Tests if the given object is the exact same instance as another.
CoreLogicalObject

• If you have several test classes, you can combine them
into a test suite.
• Running a test suite executes all test classes in that
suite in the specified order.
• A test suite can also contain other test suites.

• You can add behavior to each tests in a test class.
• This adds more flexibility to your tests.
• for example, specify which exception message you expect during the execution of your test code.
• For example, the TemporaryFolder class allows to setup files and folders which are automatically removed
after each test run.
https://github.com/junit-team/junit4/wiki/Rules

Assert.assertEquals == assertEquals

You don't write many unit tests for each
method and cover all code paths, also you
can't test all possible inputs.
But instead will want to test a variety of types
of inputs such as negative, positive, large and
small values, object's size and so on

There are quite a few ways of tackling tests for units
dealing with databases. Some of which are frowned
upon, though, such as pointing directly to the any
database.

• For example, when testing service layer, we should don't care about the data flow in unit testing.
• Or when testing controller, we should don't care about how integrate with service layer in unit testing.
A mock object is a dummy implementation for an interface or a class in which you define the output of
certain method calls. Mock objects are configured to perform a certain behavior during a test. They
typically record the interaction with the system and tests can validate that.
UserController --> UserService --> UserDAO
Mockito is a test framework with mock, stub and spy features.

• Use annotation to minimize repetitive mock/spy creation code.
• Use annotation to make the test more readable.

This is an object that has no implementation
which is used purely to populate arguments of
method calls which are irrelevant to your test.
For example, the code below uses a lot of code to
create the customer which is not important to
the test.
The test couldn't care less which customer is
added, as long as the customer count comes back
as one.

The role of the test stub is to return controlled values to the object being tested.
These are described as indirect inputs to the test.

A saboteur is used to test exceptional behaviour.

Mock objects are used to verify object behaviour during a test.
This is very different to the supporting role of a stub which is used to provide results to whatever you are testing.
In a stub we use the pattern of defining a return value for a method.
In a mock we check the behaviour of the object using the following form.

Java Unit Test - JUnit

More Related Content

What's hot (20)

Similar to Java Unit Test - JUnit (20)

Recently uploaded (20)

Java Unit Test - JUnit

Editor's Notes