Define the expected and desired output for a normal case, with correct input.
Now, implement the test by declaring a class, name it anything (Usually something like TestAddingModule), and add the testAdd method to it (i.e. like the one below) :
assertEquals(expectedVal,calculatedVal)
.Test your method by running it (in Eclipse, right click, select Run as → JUnit test).
//for normal addition
@Test
public void testAdd1Plus1()
{
int x = 1 ; int y = 1;
assertEquals(2, myClass.add(x,y));
}
Add other cases as desired.
Test that your method handles Null inputs gracefully (example below).
//if you are using 0 as default for null, make sure your class works in that case.
@Test
public void testAdd1Plus1()
{
int y = 1;
assertEquals(0, myClass.add(null,y));
}
I provide this post for both IntelliJ and Eclipse.
Eclipse:
For making unit test for your project, please follow these steps (I am using Eclipse in order to write this test):
1- Click on New -> Java Project.
2- Write down your project name and click on finish.
3- Right click on your project. Then, click on New -> Class.
4- Write down your class name and click on finish.
Then, complete the class like this:
public class Math {
int a, b;
Math(int a, int b) {
this.a = a;
this.b = b;
}
public int add() {
return a + b;
}
}
5- Click on File -> New -> JUnit Test Case.
6- Check setUp() and click on finish. SetUp() will be the place that you initialize your test.
7- Click on OK.
8- Here, I simply add 7 and 10. So, I expect the answer to be 17. Complete your test class like this:
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
public class MathTest {
Math math;
@Before
public void setUp() throws Exception {
math = new Math(7, 10);
}
@Test
public void testAdd() {
Assert.assertEquals(17, math.add());
}
}
9- Write click on your test class in package explorer and click on Run as -> JUnit Test.
10- This is the result of the test.
IntelliJ: Note that I used IntelliJ IDEA community 2020.1 for the screenshots. Also, you need to set up your jre before these steps. I am using JDK 11.0.4.
1- Right-click on the main folder of your project-> new -> directory. You should call this 'test'. 2- Right-click on the test folder and create the proper package. I suggest creating the same packaging names as the original class. Then, you right-click on the test directory -> mark directory as -> test sources root. 3- In the right package in the test directory, you need to create a Java class (I suggest to use Test.java). 4- In the created class, type '@Test'. Then, among the options that IntelliJ gives you, select Add 'JUnitx' to classpath. 5- Write your test method in your test class. The method signature is like:
@Test
public void test<name of original method>(){
...
}
You can do your assertions like below:
Assertions.assertTrue(f.flipEquiv(node1_1, node2_1));
These are the imports that I added:
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;
This is the test that I wrote:
You can check your methods like below:
Assertions.assertEquals(<Expected>,<actual>);
Assertions.assertTrue(<actual>);
...
For running your unit tests, right-click on the test and click on Run .
If your test passes, the result will be like below:
I hope it helps. You can see the structure of the project in GitHub https://github.com/m-vahidalizadeh/problem_solving_project.
This is a very generic question and there is a lot of ways it can be answered.
If you want to use JUnit to create the tests, you need to create your testcase class, then create individual test methods that test specific functionality of your class/module under tests (single testcase classes are usually associated with a single "production" class that is being tested) and inside these methods execute various operations and compare the results with what would be correct. It is especially important to try and cover as many corner cases as possible.
In your specific example, you could for example test the following:
To verify the results, you can use various assertXXX methods from the org.junit.Assert class (for convenience, you can do 'import static org.junit.Assert.*'). These methods test a particular condition and fail the test if it does not validate (with a specific message, optionally).
Example testcase class in your case (without the methods contents defined):
import static org.junit.Assert.*;
public class AdditionTests {
@Test
public void testSimpleAddition() { ... }
@Test
public void testPositiveNegativeAddition() { ... }
@Test
public void testNegativePositiveAddition() { ... }
@Test
public void testNegativeAddition() { ... }
@Test
public void testOverflow() { ... }
}
If you are not used to writing unit tests but instead test your code by writing ad-hoc tests that you then validate "visually" (for example, you write a simple main method that accepts arguments entered using the keyboard and then prints out the results - and then you keep entering values and validating yourself if the results are correct), then you can start by writing such tests in the format above and validating the results with the correct assertXXX method instead of doing it manually. This way, you can re-run the test much easier then if you had to do manual tests.
Like @CoolBeans mentioned, take a look at jUnit. Here is a short tutorial to get you started as well with jUnit 4.x
Finally, if you really want to learn more about testing and test-driven development (TDD) I recommend you take a look at the following book by Kent Beck: Test-Driven Development By Example.
Other answers have shown you how to use JUnit to set up test classes. JUnit is not the only Java test framework. Concentrating on the technical details of using a framework however detracts from the most important concepts that should be guiding your actions, so I will talk about those.
Testing (of all kinds of all kinds of things) compares the actual behaviour of something (The System Under Test, SUT) with its expected behaviour.
Automated testing can be done using a computer program. Because that comparison is being done by an inflexible and unintelligent computer program, the expected behaviour must be precisely and unambiguously known.
What a program or part of a program (a class or method) is expected to do is its specification. Testing software therefore requires that you have a specification for the SUT. This might be an explicit description, or an implicit specification in your head of what is expected.
Automated unit testing therefore requires a precise and unambiguous specification of the class or method you are testing.
But you needed that specification when you set out to write that code. So part of what testing is about actually begins before you write even one line of the SUT. The testing technique of Test Driven Development (TDD) takes that idea to an extreme, and has you create the unit testing code before you write the code to be tested.
Unit testing frameworks test your SUT using assertions. An assertion is a logical expression (an expression with a boolean
result type; a predicate) that must be true
if the SUT is behaving correctly. The specification must therefore be expressed (or re-expressed) as assertions.
A useful technique for expressing a specification as assertions is Design by Contract. These specifications are in terms of postconditions. A postcondition is an assertion about the publicly visible state of the SUT after return from a method or a constructor. Some methods have postconditions
that are invariants, which are predicates that are true before and after execution of the method. A class can also be said to have invariants, which are postconditions of every constructor and method of the class, and hence should always be true. Postconditions (And invariants) are expressed only in terms of publicity visible state: public
and protected
fields, the values returned by returned by public
and protected
methods (such as getters), and the publicly visible state of objects passed (by reference) to methods.
Many beginners post questions here asking how they can test some code, presenting the code but without stating the specification for that code. As this discussion shows, it is impossible for anyone to give a good answer to such a question, because at best potential answereres must guess the specification, and might do so incorrectly. The asker of the question evidently does not understand the importance of a specification, and is thus a novice who needs to understand the fundamentals I've described here before trying to write some test code.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With