blob: 8ad74b96bcbed1506c13defe32e7eba90e8063df (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<html>
<head>
<title>About these stubs</title>
</head>
<body>
<h2>Design</h2>
These stubs can be thought of as hand-coded mock obects. They allow unit tests to test only specific
aspects of a component while ignoring others.
These stubs form an internally consistent data-set that is not expected to change. They are
used to test the individual components in the lifecycle with data that has expected characteristics
and can be asserted as desired.
You can change/extend these stubs, and tests should not be breaking too much, since most tests
assert using expected values from the stubs. Normally, when you try to use data from the stubs that
have not been properly populated, you'll get a nullpointer in your test and you then have to
identify which stub creates that specific piece of data.
The most important stubs are:
LifecycleExecutionPlanCalculatorStub
ProjectDependencyGraphStub
Since they define the primary structure of the project/build.
The stubs define three top-level targets that are defined in LifecycleTaskSegmentCalculatorStub;
clean, aggr and install. "aggr" is an aggregating task while clean and install are lifecyclephases.
There will be three items in the task list for this dataset.
The stubs also exist at different "levels", where one test might wire stubs into a specific live implementation.
In the next test that same "live implementation" will be used in a stub version instead.
Not all live services have stubs, but can be added as needed.
</body>
</html>
|
