Menu
▾
▴
[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs naming_conventions.xml,NONE,1.1
|
From: Vincent M. <vm...@us...> - 2001-08-21 10:35:35
|
Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv29630
Added Files:
naming_conventions.xml
Log Message:
renamed "coding conventions" into "naming conventions" as this is what they are. Will add coding conventions which will be the coding conventions used internally by the Mock Objects project on its code (this will be for developers only, not for end users, whereas the naming conventions are useful to end users).
--- NEW FILE: naming_conventions.xml ---
<?xml version="1.0"?>
<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">
<document>
<header>
<title>Mock Object Naming Conventions</title>
</header>
<body>
<s1 title="Mock Object Naming Conventions">
<p>
Over time we have developed some naming conventions for how we write
mock objects which we believe make them easier to work with.
</p>
<s2 title="Creating expectations">
<p>
We have built up a library of expectation classes to help with the
development of mock objects. Each expectation object will compare
pre-loaded expected values with actual values as they arrive. Where
possible, the comparison will be made as the actual object is set,
which helps to locate errors when they occur. Each expectation class
has a constructor that takes a name value. This name will be
displayed when an assertion fails, so it should help to identify the
source of any error. For example, the instance variables for the mock
sql statement include:
</p>
<source><![CDATA[
protected ExpectationCounter myCloseCalls =
new ExpectationCounter("MockStatement.closeCalls");
protected ExpectationCounter myExecuteCalls =
new ExpectationCounter("MockStatement.executeCalls");
protected ExpectationValue myQueryString =
new ExpectationValue("MockStatement.queryString");
]]></source>
<p>
Note that the variables have the name of the thing they test,
<code>myQueryString</code> rather than
<code>myExpectedQueryString</code>. This is to avoid repetitions
such as :
</p>
<source><![CDATA[
myExpectedQueryString.setExpected(aString);
]]></source>
</s2>
<s2 title="Setting expectations">
<p>
All expectations are set with a method beginning
<code>setExpected<condition>,</code> where
<code><condition></code> is a state or behaviour that will be
verified during or at the end of the test. For example,
</p>
<source><![CDATA[
myMockHttpResponse.setExpectedContentType("text/plain");
]]></source>
<p>
says that the <code>HttpResponse</code> expects to have its content
type set to <code>"text/plain"</code> during the test.
</p>
<p>
If an expectation that a mock object supports is not set, then it
will not be verified, this makes it easier to use a mock object for
multiple tests. To check that a value is not changed during a test,
each Expectation type supports the method
<code>setExpectNothing</code>. For example, to test that no properties
of a bean have been set its mock implementation might include the
method :
</p>
<source><![CDATA[
public void setExpectNoPropertiesSet() {
myProperties.setExpectNothing();
}
]]></source>
<p>
The expectation collections include methods for adding single objects
and collections of objects. This is to allow clients to set an
expectation that is itself a collection object, perhaps to check the
identity of an array, rather than its contents. When using a
collection expectation in a mock object please be clear in your
expectations whether you are adding to or overriding the current
expected values. For example, the method :
</p>
<source><![CDATA[
public void addExpectedProperty(String property) {
myProperties.addExpected(property);
}
]]></source>
<p>
adds an additional property that the mock object will expect to
receive. The method :
</p>
<source><![CDATA[
public void setExpectedProperty(String property) {
myProperties.setExpectNothing();
myProperties.addExpected(property);
}
]]></source>
<p>
resets the property expectation.
</p>
</s2>
<s2 title="Setting actual values">
<p>
The actual values for comparison against the expected values will be
set in the mock implementations of real methods. For example, we
count the number of times <code>close</code> is called in a mock sql
statement in the method :
</p>
<source><![CDATA[
public void close() throws SQLException {
myCloseCalls.inc();
}
]]></source>
<p>
similarly, to set a positional parameter in a mock prepared
statement :
</p>
<source><![CDATA[
public void setObject(int param, Object obj) throws SQLException {
mySetParameters.addActual(new MapEntry(new Integer(param), obj));
}
]]></source>
</s2>
<s2 title="Setting stub values">
<p>
Many mock objects are used for both validation of expectations and
as stub implementations to allow tests to run without external
dependencies. For example, we often need to set parameters values in
a mock servlet request for the target code to retrieve; these
properties values are not verified because we are testing how they
are used, not how they are set. The setter method is :
</p>
<source><![CDATA[
public void setupAddParameter(String paramName, String value) {
setupAddParameter(paramName, new String[] { value });
}
]]></source>
<p>
Our convention is that stub methods start with
<code>setup<state></code> to distinguish them from Java setter
methods which have the format <code>set<state></code>.
Stub values are used by mock implementations of real methods.
</p>
<p>
One unusual stub setting we use quite often is to force exceptions
to be thrown. For example, the mock sql statement includes the
method :
</p>
<source><![CDATA[
public void setupThrowExceptionOnExecute(SQLException exception);
]]></source>
<p>
The statement stores the given exception object and throws it when
<code>execute()</code> is called. This technique is sometimes the
only way to test certain types of failure.
</p>
</s2>
</s1>
</body>
</document>
|
