JUnit Best Practices

JUnit Best practices?

Martin? Fowler (again the Tall man) said: "When you try to print out some information or debug an expression, write some test code to replace those traditional methods." "In the beginning, you will find that you are always creating some new fixture, and the test seems to slow down your programming speed. Soon, however, you'll find that you re-use the same fixture, and the new test usually involves adding a new test method.

You might write a lot of test code, but you'll soon find that only a fraction of the tests you envision are really useful. The tests you need are those that will fail, those that you don't think will fail, or tests that you think should fail but succeed.

We mentioned earlier that testing is a process that will not be interrupted. Once you have a test, you should always ensure that it works properly to verify the new work code you are joining. Do not run the tests every few days or at the end, and you should run the test code every day. This is a small investment, but it ensures that you get a working code that you can rely on. Your rework rate is reduced and you will have more time to write your work code.

Do not assume that the pressure is high, do not write the test code. Instead, writing test code will relieve your stress, and you should have a clear understanding of the behavior of the class by writing test code. You'll be writing a working code that works more quickly and efficiently. Here are some specific techniques for writing test code or a good practice approach:

1. Do not initialize the fixture with the TestCase constructor, but use the setup () and teardown () methods.
2. Do not rely on or assume the order of test runs, because JUnit uses vectors to save test methods. So different platforms will remove the test method from the vector in different order.
3. Avoid writing testcase that have side effects. For example, if the subsequent test relies on certain transaction data, do not submit the transaction data. Easy to roll on.
4. When inheriting a test class, remember to call the Setup () and teardown () methods of the parent class.
5. Put the test code and the work code together, while compiling and updating synchronously. (Use ant with a task that supports JUnit.)
6. The test class and test methods should have a consistent naming scheme. If you precede the work class name with test to form the testing class name.
7. Make sure the test is time-independent, and do not rely on testing with outdated data. This makes it difficult to reproduce the test during the subsequent maintenance process.
8. If you are writing software for the international market, consider internationalization factors when writing tests. Do not test only in your native language locale.
9. Use the JUnit Assert/fail method and exception handling methods as much as possible to make the code more concise.
10. Test to be as small as possible and execute fast.

In fact, JUnit can also be used for integration testing, but I'm not involved for two reasons: because there is no unit test, integration testing is not a problem. It is not easy for us to accept the concept of testing, and it will be more difficult to introduce integration tests. Second, I am lazy, I hope the integration test task to the testers to do. There are some articles on the JUnit website that you can turn over when you are free.


JUnit and the EE?

If you think about it, you'll find that JUnit has its own limitations, such as testing the graphical interface, and we haven't given any examples of servlet/jsp and EJB testing. In fact, JUnit has a way of testing the GUI interface, Servlet/jsp,javabean, and EJBs. The testing of the GUI is more complicated, and it is suitable to be introduced in a whole article. There's not much to say here.

The test we did in the first place actually had an implicit environment in which our class needed to execute the JVM. In the Java EE Framework, SERVLET/JSP,EJB requires its own operating environment: the WEB? Container and EJB? Container. So, to test servlet/jsp,ejb, you need to deploy it in the appropriate container to test it. Since EJB does not involve UI issues (unless the EJB is manipulating XML data, the test code is difficult to write at this time, it may be necessary for you to compare whether two dom trees contain the same content) as long as you can run the test code after deployment. The Setup () method is particularly useful at this point, and you can use Jndi to find specific EJBS in the Setup () method. The methods of these ejbs are called and tested in the Testxxx () method.

The JavaBean referred to here also has no UI problems, for example, we use JavaBean to access the database, or to wrap ejbs with JavaBean. If this type of JavaBean does not use the services provided by container, it can be tested directly, just as we have previously mentioned in the general class of test methods. If this type of JavaBean uses the services provided by container, it needs to be deployed in container to be tested. method is similar to EJB.

Testing for servlet/jsp is tricky, and it is recommended that HttpRequest and HttpResponse be constructed in the test code, and then compared, which requires developers to have a deeper understanding of the HTTP protocol and the internal implementation of servlet/jsp. I don't think the trick is realistic. It has also been suggested to use HttpUnit. Because I don't know much about cactus and httpunit, I can't make the right suggestions. I hope that the prophets will be very generous to enlighten you.

It is because of the openness and simplicity of junit that this introductory article is introduced. But the technology is constantly being updated, and I have no very deep understanding of the test; I can simplify a complex concept into a very easy to understand word. But my intention was only to reduce the threshold for developers to step into the field of testing, rather than to modify or redefine some concepts. This is a particular point to be emphasized. Finally, I would be very grateful if some of my siblings could give me some points of attention or my understanding of certain issues was wrong.