Pragmatic unit testing in java with JUnit

Pragmatic unit testing in java with JUnit
-- Unit test background

My internship in the company has been very fulfilling for the past two weeks, but I am also very tired. I am tired of working in a different way than before. Although the tone is the same, there are many differences in details, the current project is very large and important. The technical manager intends to adopt a more standardized and stricter development model. Therefore, testing is one of the key points, read the pragmatic unit testing in java with JUnit by Andrew hunt David Thomas, and then read the JUnit documents to extract some key points and good ideas.

Testing practices
Martin Fowler makes this easy for you. He says, "whenever you are tempted to type something

Into a print statement or a debugger expression, write it as a test instead. "At first you

Will find that you have to create a new fixtures all the time, and testing will seem to slow

You down a little. Soon, however, you will begin reusing your library of fixtures and new

Tests will usually be as simple as adding a method to an existing testcase subclass.

You can always write more tests. However, you will quickly find that only a fraction of

Tests you can imagine are actually useful. What you want is to write tests that fail even

Though you think they shoshould work, or tests that succeed even though you think they shoshould

Fail. Another way to think of it is in cost/benefit terms. You want to write tests that will

Pay you back with information.

Here are a couple of the times that you will receive a reasonable return on your testing

Investment:

* During Development-when you need to add new functionality to the system, write

Tests first. Then, you will be done developing when the test runs.
* During debugging-when someone discovers a defect in your code, first write a test

That will succeed if the code is working. Then debug until the test succeeds.

One word of caution about your tests. Once you get them running, make sure they stay

Running. There is a huge difference between having your suite running and having it broken.

Ideally, you wocould run every test in your suite every time you change a method. Practically,

Your suite will soon grow too large to run all the time. Try to optimize your setup code so

You can run all the tests. Or, at the very least, create special suites that contain all

Tests that might possibly be affected by your current development. Then, run the suite every

Time you compile. And make sure you run every test at least once a day: overnight,

Lunch, during one of those long meetings ....
Conclusion
This article only scratches the surface of testing. However, it focuses on a style

Testing that with a remarkably small investment will make you a faster, more productive,

More predictable, and less stressed developer.

Once you 've been test infected, your attitude toward development is likely to change. Here

Are some of the changes we have noticed:

There is a huge difference between tests that are all running correctly and tests that

Aren't. Part of being test infected is not being able to go home if your tests aren't 100%.

If you run your suite ten or a hundred times an hour, though, you won't be able to create

Enough havoc to make you late for supper.

Sometimes you just won't feel like writing tests, especially at first. Don't. However, pay

Attention to how much more trouble you get into, how much more time you spend debugging, and

How much more stress you feel when you don't have tests. We have been amazed at how much

More fun programming is and how much more aggressive we are willing to be and how much less

Stress we feel when we are supported by tests. The difference is dramatic enough to keep us

Writing tests even when we don't feel like it.

You will be able to refactor much more aggressively once you have the tests. You won't

Understand at first just how much you can do, though. Try to catch yourself saying, "Oh, I

See, I shoshould have designed this thus and so. I can't change it now. I don't want to break

Anything. "When you say this, save a copy of your current code and give yourself a couple

Hours to clean up. (This part works best you can get a buddy to look over your shoulder

While you work.) Make your changes, all the while running your tests. You will be surprised

At how much ground you can cover in a couple of hours if you aren't worrying every second

About what you might be breaking.

For example, we switched from the vector-based implementation of moneybag to one based on

Hashtable. We were able to make the switch very quickly and confidently because we had so

Deletests to rely on. If the tests all worked, we were sure we hadn't changed the answers

The system produced at all.

You will want to get the rest of your team writing tests. The best way we have found

Spread the test infection is through direct contact. The next time someone asks you for help

Debugging, get them to talk about the problem in terms of a fixture and expected results.

Then say, "I 'd like to write down what you just told me in a form we can use." Have them

Watch while you write one little test. Run it. Fix it. Write another. Pretty soon they will

Be writing their own.

So-Give JUnit a try. If you make it better, please send us the changes so we can spread

Them around. Our next article will double click on the JUnit framework itself. We will show

You how it is constructed, and talk a little about our philosophy of framework development.

We wowould like to thank Martin Fowler, as good a programmer as any analyst can ever hope

Be, for his helpful comments in spite of being subjected to early versions of JUnit.

========================================================== ========================================================== ================
Properties of good tests
Quality of good testing
A-TRIP

• Automation)
• Thorough (thorough)
• Repeatable)
• Independent (independent)
• Professional </LI>

Combat slogan "Do not repair and supplement, completely rewrite"

========================================================== ========================================================== ================

Test courtesy

• Incomplete code
• Not cheap code
• Code can be cheap, but it will break out existing code, such as making existing code compilation fail
• No code for the unit test
• Code that cannot pass unit test
• Code that passes your own test, but causes other test failures elsewhere in the system </LI>

========================================================== ========================================================== ================
Encoding and review are conducted in this order:
1. Write test case and/or test code
2. Review test case and/or test code
3. modified test case and/or test code after review
4. Compile product code that can pass all tests
5. Review product code and test code
6. After each review, modify the test code and product code.
========================================================== ========================================================== ================
Correct Boundary Condition

• Conformance-does the value conform to the expected format?
• Ordering-is a set of values ordered or unordered?
• Range: Is the value within the range of a reasonable maximum and minimum?
• Reference: Does the code reference external factors that are not directly controlled by the Code itself?
• Existence -- does a value exist (for example, non-null, non-zero, including a set )?
• Cardinality-Is there enough?
• Time, absolute or relative (time) -- is everything happening in order? At the right time? Timely?