|
|
|
SilverMark
Newsletters
March
2002 Issue
IN
THIS ISSUE:
A
brief introduction to the new Java 1.4 assert facility
-------------------------------------------------------------------------------------------
The Java SDK 1.4 distribution includes a new assert keyword that
enables you to employ a measure of design-by-contract within your
code. An assertion is a statement that contains a boolean expression
that is believed to be true at the time the statement is executed.
By adding statements to verify various conditions, the system corroborates
your assumptions about it at runtime, increasing your confidence
that it is working correctly.
Test cases are programs that exercise your Java components (classes
and frameworks) during development across a variety of usage scenarios,
in order to validate that they work correctly.
This article discusses how these two component validation techniques
relate to each other and when to use them.
Syntax
The syntax for the assert facility is:
|
AssertStatement:
assert
Expression1;
assert Expression1 : Expression2 ;
|
For example:
|
/**
* Look up the life expectancy of a person, given their profile
*
* @param profile, a profile describing a person
* @return expected lifetime in months
*/
public int lookupActuarial(PersonProfile profile) {
// Precondition validation
assert profile.isValid();
int answer;
**** perform lookup here ****
// Postcondition validation
assert answer > 0 && answer <= 100
return answer;
}
|
In
the case of the new assert facility, if an assertion fails it causes
a java.lang.AssertionError to be thrown.
You can place asserts in your code and then enable or disable them
at a class or package level with javac command line options.
There is no facility to enable or disable them at compile time,
although you can disable it programmatically using the "conditional
compilation" idiom described in JLS 14.19:
static
final boolean asserts = ... ; // false to eliminate asserts
if (asserts)
assert <expr> ; |
About Design By Contract
Design by contract specifies that you add assertions as part of preconditions,
postconditions, and class invariants.
A
precondition is a condition that must be met prior to proceeding
with some operation. For example, if you have a BankAccount object,
a precondition to proceeding with a 'withdraw' operation is that
there is enough of a balance present to satisfy the request. You
should be careful that you place the precondition validation in
the correct place. In this example, you would place the balance
check at a point where all other error checking about an excessive
withdrawal (including user notification) is presumed to have been
performed.
A
postcondition is a condition that must be met after some operation
has been performed. For example, for checking that a calculated
value is within some expected bounds.
A
class invariant is a condition that must be met under all conditions.
That is, it is applicable to the entire class regardless of which
operations have been performed or the order. The most common example
is an assertion that a queue's size is never less than zero.
Observations
Test cases apply external stimuli to your objects and validate their
state. The assert facility enables you to specify constraints internally
and detect them through the java.lang.AssertionError
exception. These are two different but complementary approaches to
testing.
Given this, one can make several observations about usage of the assert
feature vs. test cases:
-
Assert statements within code help clarify internal assumptions
and constraints. This certainly helps document the implementation,
which leads to better understanding of the code.
-
Assert statements in classes delivered without source are not
visible to the consumer.
- Test
cases help document correct usage of the objects under test. That
is, they are intention revealing devices.
-
Assertions, unlike test cases, are of no use in validating input
vs. expected output across a range of scenarios.
- Assertions
can have performance implications unless they are turned off
-
Unlike test cases, assertions are runtime artifacts, and can provide
continuous and ongoing validation. This helps guard against difficult
to test conditions such as numeric tolerance drift and thread
safety issues.
- Test
cases generally can only validate what is publicly visible, whereas
assertions can be used to perform validation deep within private
methods.
A
few recommendations for effective use of the assertion facility
during component testing
Both approaches have their advantages and disadvantages. Fortunately
your are not faced with an either-or decision. The best approach
is to leverage the advantages that each approach offers, while avoiding
potential pitfalls:
- It
is certainly reasonable to rely on assertions to perform constraint
validation. During test execution violations cause
java.lang.AssertionError
exceptions to be thrown, which will be trapped and logged by the
test framework. They will also serve as continuous runtime diagnostics.
- You
will need test cases to apply stimuli to your system, across a
set of use case scenarios.
- You
should include test case based validation to ensure that objects
are in expected state, given a reasonable range of input values.
By state, we mean the state of instance variables after a particular
stimulus has been applied to an object, as well as returned values.
Remember that internal assertions only validate according to constraints.
They are not effective for validating expected output for a given
input.
-
Do not use assertions in place of method input parameter validation,
except in the case where you are asserting that the validation
has correctly taken place and only 'good' values are expected
at a given point in the code.
For example, consider that case where a user enters a value for
a calculation. You should not use the assertion facility to validate
that the user has entered data within the correct range. However
it is reasonable to use the assertion facility downstream where
only correct values are expected.
More
information about the assertion facility:
http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html
More information about design by contract
http://www.eiffel.com/doc/manuals/technology/contract/
Enterprise Architects Corner
-------------------------------------------------------------------------------------------
By Stephen N. Crans, Chief Science Officer,
Java Commandos, crans@jcommandos.com
Once
you get past the initial joy of learning how to test string, char,
int and other basic attributes, and methods with simple return types,
you start to get into the advanced world of test architecture. Test
Infected examples don't help you very much here, do they?
In
this corner of the SilverMark newsletter we will talk about such
things and introduce advanced solutions to advanced problem. Problems
normally left to the top technical person in an enterprise. We will
call just a person the Enterprise Architect.
Setting Priorities for Legacy
Component Testing Development
-------------------------------------------------------------------------------------------
Kent Beck, not withstanding, most Java Components are found
in application architecture that was not developed with the test
first approach! Consider the ugly reality of legacy application
architecture that does not have component testing architecture to
go with it. Yes you have your copy of Test Mentor - Java Edition.
And yes you can generate starter code for all this legacy architecture,
but can you really take in on all at once?
[Methodology
Side Bar: Consider the python and the lion. The lion can eat an
elephant, but the python cannot. Why? A lion tears off one piece
at a time, the python must eat its food all in one bite. More over,
lions share the food. Finally, the elephant may provide many meals
for the lions eating it. Does this remind you of software engineering
teams sharing software development responsibilities? In our example,
we have divide up the elephant by lion and by meal, don't we? Hopefully,
we can do it with less growling and fighting than the actual lions
do. ]
At
some point, someone is going to have to make choices about what
java component testing architecture should be created first for
this legacy architecture. How will you do that? One approach is
to apply metrics to the software to help guide your decision. At
Java Commandos, we use metrics that indicate a high probability
of maintenance being needed to guide our investment in advanced
test architecture. This can be based on a variety of considerations
such as interdependence between classes (based on collaboration
or inheritance) and various complexity indicators at the methods
level. We use this analysis to create a weighed priority for each
java component that can be used to assign such development to Java
Development teams along with user mandated features, etc. These
can be organized into block points or releases described in various
agile methodologies. [A block point is a coordinated release of
application architecture with the supporting and testing architecture
that goes with it.] We will go into this selection of new test architecture
for development in greater details in later newsletters and of course
we provide training on how to do that in the real world!
The
Economics of Test Architecture Development and Use
-------------------------------------------------------------------------------------------
Another aspect of large-scale test architecture
development is the economics of it. At some point the people who
pay for such things are going to ask why? Your answer will be to
reduce the head count for maintaining a given amount of code, speed
up the development of new code, etc., of course, but such investment
is not an absolute value. What is enough investment in test architecture?
How do you justify it and how does this justification in test architecture
change when you have tools like Test Mentor - Java Edition to improve
both the speed of such development and the quality of its use?
[Economics
Sidebar: In many ways investing in test architecture is like investing
in airline safety. Just as you want to know who gets on the plane
and what they bring with them, you also want to know what software
gets on the computer and what data it brings with it. In both cases,
only a very small part is bad, but in both cases, even that small
part can be intolerable. How do you know what is enough? How do
you manage change until you have enough? ]
We
have known for at least a generation, that we need to use software
to test software components. We have not done very much up until
now, because it was too hard. With advent of JUnit and all the various
frameworks that help us to create such test architecture, it is
now becoming easier. This is both good news and bad news. The good
news is that we are creating more test architecture. The bad news
is that much of this test architecture is not very helpful or not
very well done. Test Mentor - Java Edition can change that in the
hands of people with the necessary training. Well-formed test architecture
that tests what is most important is a very good investment. Poorly
developed test architecture or test architecture that test components
that are unimportant are not. We will be discussing this further
in later newsletters and of course we provide training on how to
address this in the real world.
Test Mentor V5.4 Released
--------------------------------------------------------------------------------------------
The SilverMark engineering team is pleased to announce the
release of Test Mentor - Java Edition V5.4. This release includes
the following new and enhanced features:
-
Stronger collaboration between developers and testers
- Automatically
create tests from recorded Object Interactions
- Enhanced
automatic test generation in three formats:
- Visually
composed tests for QA teams
- Java
code for developers
- Pure
JUnit tests
-
Deeper integration with JUnit framework
- Discover,
execute and generate JUnit tests
- Deeper
integration with popular Java development environments (IDEs)
-
Code coverage profiling
- Transparent
access to private methods, constructors and fields
-
Distributed Object Testing
-
Fine-Grained Performance Validation
Links to more information:
A sneak peek at upcoming product: Enhanced
JUnit
--------------------------------------------------------------------------------------------
SilverMark's engineers have been at
it again. If you've heard about JUnit, you know it's a simple, open-source
Java test framework.
In the next few weeks SilverMark will be announcing availability
of a prerelease version of our Enhanced JUnit product, which adds
a lot of your favorite Test Mentor technology directly to JUnit,
plus a few surprises.
Enhanced JUnit adds the following features to JUnit:
-
Automatic Test generation - generate test cases using Test Mentor's
test generation facilities
- Load
testing - distribute your existing JUnit tests across hundreds
or thousands of concurrent threads and CPUs to validate that your
system can handle the necessary load
-
Method coverage profiling - Find out which methods are being covered
by your JUnit tests and which ones are being left out
- Data-driven
testing APIs - create tests that iterate over test data, without
writing a lot of code
- Other
convenience APIs and utilities
Enhanced
JUnit does not alter JUnit. It simply adds additional features to
it. Also, Enhanced JUnit is not Test Mentor, although it does share
some code with it. If you are interested in more information about
Enhanced JUnit, please send and email to enhancedjunit@javatesting.com.
Training
Corner
--------------------------------------------------------------------------------------
SilverMark
is please to announce the alliance partnership with Java Commandos,
an advanced Java research, development and instruction corporation
with headquarters in the Kansas City metropolitan area. Java Commandos
is creating training materials to be used by SilverMark Alliance
partners around the world under a joint copyright agreement. These
materials are innovative in several important ways.
- All
Instructor Lead Training materials are organized into learning
objective modules that consist of instructor lecture presentation
slides, supporting instructor notes and Test Mentor - Java Edition
examples, student exercises and student tests.
- The
set of these modules are organized into a menu and are sold on
the "American salad bar" plan.
- Under
this plan you can buy salad by the pound and put what you
want on your plate. Usually there is a wide variety of food,
condiments and dressings. Every picks what they want according
to their personal needs and preferences.
-
With training there are a few changes: Usually, the modules
are selected based on the difference between what the students
have already taught themselves and what they need to use the
product successfully. Basically the customer buys training
days at a fixed price and fills them up with training modules
to taste!
-
Computer Based Testing and Certification is used to pretest and
posttest the degree of learning objective mastery for each student.
- The
difference between the pre and posttest scores is the amount
learned.
-
The pretest indicates the relative need for various learning
object modules.
-
The posttest grade provides the basis for certification that
the student pasted the course. An average grade of 70% is
required on the modules covered.
-
This technology is much the same as that used in the Sun Certification
for Java Programming.
- It
is a large database of test items classified by learning
objective. These test items can be selected on a weighted
basis for membership in a student's particular test.
- This
makes all tests different, but allows appropriate coverage
for these learning objectives.
- Examples
of Test Mentor - Java Edition major learning objectives (which
span multiple learning object modules) include:
- Test
Architecture Computer Science
-
Test Mentor Java Edition Tool Skills
-
Test Architecture Work Flow
-
Test Architecture Economics
-
More detailed information on this new training will be provided
as learning modules become available for general use.
- For
more information contact the Chief Science Officer at Java
Commandos: crans@jcommandos.com.
|
Consultant's Corner
--------------------------------------------------------------------------------------------
Want to use Test Mentor as a part of
your consulting tools arsenal? SilverMark is currently offering
a consultant's discount program to provide low cost licenses to
consulting groups and independent consultants. Due to an overwhelming
number of requests, we are also providing a Test Mentor certification
program beginning first quarter of 2001.
SilverMark is committed to supporting educational institutions.
To help ensure that students of object-oriented software application
development have an opportunity to succeed in the ever-changing
market of available tools we are pleased to offer Test Mentor
Products for use in teaching environments. Please click here
for to sign up.
|
Privacy
Statement & How to Unsubscribe
--------------------------------------------------------------------------------------------
SilverMark respects your privacy and
NEVER sells any contact information. This newsletter has been sent
to you because you are a licensed user of one of our products or
at one time expressed interest in our products and/or services.
To unsubscribe to this newsletter, reply to this email and write
"unsubscribe" (no quote marks) in the subject line.
To change your email address, reply to this email with "change"
(no quote marks) in the subject line. We will pick up your return
address.
**If this article has been forwarded to you by a friend, you can
register for your own free subscription to Java Testing Newsletter
by sending an email to
subscribe@javatesting.com
--------------------------------------------------------------------------------------------
|
Learn how to use these
tools: JUnit, Cactus, EJBUnit,
HTTPUnit, Clover, Jester, MockMaker, EasyMock, JFCUnit, Jemmy, Abbot, NoUnit,
JUnit-addons, JUnitPerf, Enhanced JUnit, DBUnit, SQLUnit, FIT, FITnesse, WATT,
ANT, Test Mentor, and JTest.
