Java Open Source Testing tool JUnit Introduction

1. Introduction

In an earlier article (see Test Infected:programmers Love writing Tests, Java Report, July 1998, Volume 3, number 7), we described how to use a simple framework to edit Write repeatable tests. In this article we'll take a quick glance at the details in it and show you how the framework itself is structured.

We study the Juint framework in detail and think about how to construct it. We have found many lessons at different levels. In this article, we will try to communicate with them immediately, which is a desperate task, but at least it is done in the context of our showing you the design and construction of a software that is worth proving.

We have raised a discussion about the objectives of the framework. During the expression of the framework itself, the target repeats itself in a number of small details. After that, we propose the design and implementation of the framework. The design will be described in terms of the pattern (surprise, surprise) and be implemented as a graceful program. We have summed up some excellent ideas about the development of the framework.

2. What is the goal of JUnit?

First, we have to go back to the assumption of development. If you are missing an automated test of a program feature (automated test), we assume that it will not work. This looks more secure than the mainstream assumption that if the developer assures us that a program feature works, it will work forever now and in the future.

From this point of view, when developers write and debug code, their work is not done, they also have to write tests to demonstrate that the program can work. However, everyone is too busy, they have to do too much, they do not have enough time for testing. I already have too much code to write, how can I write test code again? Answer me, Mr. Tough project manager. The primary goal, therefore, is to write a framework in which developers can see the light of hope that the actual test will be written. The framework must use common tools to learn that there are not too many new things. It cannot be more than the work required to fully write a new test. Duplication of work must be excluded.

If all the tests do this, you will be able to write an expression in just one debugger to do it. However, this is not sufficient for testing. Tell me your program can work now, it doesn't help me, because it doesn't guarantee that your program will work every minute since I integrate now, and that it hasn't assured me that your program will still be able to work for five years, when you've been away for a long time.

As a result, the second goal of the test is to generate a test that will sustain its value. Anyone other than the original author must be able to perform tests and explain their results. You should be able to combine the tests of different authors and run them together without having to worry about conflicting.

Finally, you must be able to generate new tests with existing tests as a fulcrum. Generating a device (Setup) or fixture (fixture) is expensive, and a framework must be able to reuse the fixture to run different tests. Oh, is there anything else?

Design of 3.JUnit

The JUnit design will be a first in Patterns Generate architectures (see "Patterns Generate Architectures", Kent Beck and Ralph Johnson, Ecoop 9 4) in the style used to render. The idea is to apply patterns from scratch, and then one by one until you get a system architecture to explain the design of a system. We will present the architectural issues that need to be addressed, summarize the patterns used to solve the problem, and then show how to apply the schema to JUnit.

3.1 This starts-testcase

First we must construct an object to express our basic concepts, TestCase (test case). Developers often have test cases in their minds, but there are many different ways to implement them-

· Print Statements

· Debugger expressions

· Test scripts

If we want to easily manipulate tests, we must build them into objects. This will capture a test that is simply hidden in the developer's mind and be materialized, supporting the goal of creating tests that sustain their value. At the same time, object developers are more accustomed to using objects for development, so the decision to build the tests into objects supports our goal-making the test writing more appealing (or at least less gorgeous).

Command mode (see Gamma, E., et al. Design patterns:elements of reusable object-oriented Software, Addison-wesley, Reading , MA, 1995) will be able to better meet our needs. Quotations of its intent (intent), "encapsulate a request into an object so that you can parameterize the client with different requests, queue or log request logs for requests ... command tells us that an object could be generated for an operation and given an" execute " Method. The following code defines the TestCase class:

public abstract class TestCase implements Test {
…
}