A test to make sure that the code you write works as expected. Also called a unit test. JUnit is a very famous framework for unit testing in Java. Writing test programs using a common framework makes it easier for others to modify their test programs.
https://stackoverflow.com/questions/19330832/setting-up-junit-with-intellij-idea https://www.slideshare.net/SatoshiKubo1/junitjava
Various asserts are used to confirm the test results. assertEquals() → Determine if the expected result is the same as the actual result. Argument 1: (expected, actual) Argument 2: (String message, expected, actual) --A message is displayed if the test fails. Argument 3: (expected, actual, delta) --delta is the tolerance. Argument 4: (String message, double expected, double actual, double delta)- assertNotNull() → Judge whether the given Object is not null. Argument 1: (Object object) Argument 2: (String message, Object object) --A message is displayed if the test fails. assertNull() → Judge whether the given Object is Null. Argument 1: (Object object) Argument 2: (String message, Object object) --A message is displayed if the test fails. assertSame() → Judge whether the given two Objects refer to the same Object. Argument 1: (Object expected, Object actual) Argument 2: (String message, Object object) --A message is displayed if the test fails. assertTrue() → Judge whether the given conditions are correct. Argument 1: (Object expected, Object actual) Argument 2: (String message, Object object) --A message is displayed if the test fails. assertThat() In combination with Matcher, it is more convenient than assertEquals (). There is a limit to assertEquals () because only one equals () can be created for an object. Since it is Matcher, not assertThat, that is verified, it is highly extensible. The situation of writing assert Equals on multiple lines no longer occurs. Arguments: (Object actual, Matcher matcher) Details
The methods in the test class are not executed in order from the top. Therefore, do not write test methods that assume the above test results.
Do not create "side effects" that change the state of the system, such as updating the database when testing.
So that those who read the code later can quickly understand the purpose of the test.
Same as above. Simple and easy to understand without waste.
Writing manually + many mistakes + hard to keep up with updates.
To be able to test frequently and easily.
If you want to perform common processing (database connection / disconnection, etc.) at the beginning and end of multiple methods, use the setUp () and tearDown () methods. setUp() Executed before each test method is called. tearDown() Executed after the end of each test method.
As mentioned above, the test methods are not executed in the order they are written, but you can use the TestSuite class to specify the order in which the test methods are executed.
Recommended Posts