You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@isis.apache.org by bu...@apache.org on 2014/12/11 13:57:27 UTC
svn commit: r932284 - in /websites/staging/isis/trunk: cgi-bin/ content/
content/more-advanced-topics/Fixture-Scripts.html
Author: buildbot
Date: Thu Dec 11 12:57:27 2014
New Revision: 932284
Log:
Staging update by buildbot for isis
Modified:
websites/staging/isis/trunk/cgi-bin/ (props changed)
websites/staging/isis/trunk/content/ (props changed)
websites/staging/isis/trunk/content/more-advanced-topics/Fixture-Scripts.html
Propchange: websites/staging/isis/trunk/cgi-bin/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Dec 11 12:57:27 2014
@@ -1 +1 @@
-1644613
+1644617
Propchange: websites/staging/isis/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Dec 11 12:57:27 2014
@@ -1 +1 @@
-1644613
+1644617
Modified: websites/staging/isis/trunk/content/more-advanced-topics/Fixture-Scripts.html
==============================================================================
--- websites/staging/isis/trunk/content/more-advanced-topics/Fixture-Scripts.html (original)
+++ websites/staging/isis/trunk/content/more-advanced-topics/Fixture-Scripts.html Thu Dec 11 12:57:27 2014
@@ -453,7 +453,7 @@ archetype also does something very simil
<h2>Using Fixture Scripts in the UI</h2>
<p>The normal convention is to for the (application's) fixture script service to be surfaced on a "Prototyping" menu. Here's
-how the todoapp defines its fixture script service:</p>
+how the <a href="../intro/getting-started/todoapp-archetype.html">todo app</a> defines its fixture script service:</p>
<pre><code>@DomainService
@DomainServiceLayout(
@@ -497,7 +497,7 @@ to any of the objects created/updated by
<p>Fixture scripts can be invoked in integration tests by injecting the <code>FixtureScripts</code> service and then using the service to execute the required fixture script.</p>
-<p>For example, here's one of the todo app's integration tests:</p>
+<p>For example, here's one of the <a href="../intro/getting-started/todoapp-archetype.html">todo app</a>'s integration tests:</p>
<pre><code>public class ToDoItemIntegTest extends AbstractToDoIntegTest {
@@ -536,7 +536,7 @@ to any of the objects created/updated by
</code></pre>
<p>The lookup key is the same as is rendered in the UI, and is also printed to the console. (Although not done in the
-todo app) it's probably good practice to encapsulate this string within the fixture script subclass, eg:</p>
+<a href="../intro/getting-started/todoapp-archetype.html">todo app</a>) it's probably good practice to encapsulate this string within the fixture script subclass, eg:</p>
<pre><code>public class ToDoItemsRecreateAndCompleteSeveral extends FixtureScript {
...
@@ -601,7 +601,7 @@ todo app) it's probably good practice to
</ul>
<pre>
- executeChild(this, someObject);
+ executionContext.executeChild(this, someObject);
</pre>
<ul>
@@ -617,7 +617,7 @@ into the database). One way of doing th
do the same. This can lead to unmaintainable tests, however: if the business logic changes, then the knowledge encoded
in those SQL statements will be out-of-date.</p>
-<p>A better approach, therefore, is to have the fixture scripts simply invoke the relevant actions and other business logic
+<p>Therefore a better approach is to have the fixture scripts simply invoke the relevant actions and other business logic
on the domain objects. Then, if those actions change in the future, the scripts remain valid. Put another way: have
the fixture scripts replay the "cause" of the change (business actions) rather than the "effect" (data inserts).</p>
@@ -632,7 +632,7 @@ the fixture scripts replay the "cause" o
<h3>Example Usage</h3>
-<p>The todo app (generated by the <a href="../intro/getting-started/todoapp-archetype.html">todo app archetype</a> uses fixture
+<p>The <a href="../intro/getting-started/todoapp-archetype.html">todo app</a> uses fixture
scripts to create a number of todo items, in different states (some complete, some not). Its design is:</p>
<ul>
@@ -659,7 +659,7 @@ In practice though we recommend keeping
<h3>Action script examples</h3>
-<p>The todo app's <code>ToDoItemForBuyStamps</code> fixture script creates a single, not yet complete todo item:</p>
+<p>The <a href="../intro/getting-started/todoapp-archetype.html">todo app</a>'s <code>ToDoItemForBuyStamps</code> fixture script creates a single, not yet complete todo item:</p>
<pre><code>public class ToDoItemForBuyStamps extends ToDoItemAbstract {
@@ -677,7 +677,7 @@ In practice though we recommend keeping
}
</code></pre>
-<p>where in turn <code>ToDoItemAbstract</code> inherits from <code>FixtureScript</code>:</p>
+<p>where in turn <code>ToDoItemAbstract</code> inherits from <code>FixtureScript</code> and provides the <code>createToDoItem(...)</code> method:</p>
<pre><code>public abstract class ToDoItemAbstract extends FixtureScript {
@@ -699,24 +699,14 @@ In practice though we recommend keeping
description, category, subcategory, ownedBy, dueBy, cost);
return executionContext.addResult(this, newToDo);
}
-
- protected LocalDate nowPlusDays(int days) {
- return clockService.now().plusDays(days);
- }
-
- protected BigDecimal BD(String str) {
- return new BigDecimal(str);
- }
+ ...
@javax.inject.Inject
private ToDoItems toDoItems;
-
- @javax.inject.Inject
- protected ClockService clockService;
}
</code></pre>
-<p>It's also possible for fixture scripts to call prerequisite fixture scripts. So, this fixture script will create the "buy stamps" todo item and then complete it:</p>
+<p>Similarly, the following fixture script looks up a todo item (assumed to have been created earlier on) and then complete it:</p>
<pre><code>public class ToDoItemCompleteForBuyStamps extends ToDoItemCompleteAbstract {
@@ -735,7 +725,7 @@ In practice though we recommend keeping
String ownedBy = executionContext.getParameter("ownedBy");
final ToDoItem toDoItem = findToDoItem(description, ownedBy);
toDoItem.setComplete(true);
- executionContext.add(this, toDoItem);
+ executionContext.addResult(this, toDoItem);
}
private ToDoItem findToDoItem(final String description, final String ownedBy) {
@@ -822,15 +812,15 @@ In practice though we recommend keeping
<p>While we suggest that you organize fixture scripts in two levels - coarse-grained scenario scripts and fine-grained action scripts - you can if you wish create deeper hierarchies than this. Put another way: fixture scripts form a hierarchy (composite pattern) and the nesting can be as deep as you require.</p>
-<p>The todo app's fixture hierarchy as implemented is quite flat:</p>
+<p>The <a href="../intro/getting-started/todoapp-archetype.html">todo app</a>'s fixture hierarchy as implemented is quite flat:</p>
-<p><img src="images/fixture-scenario-hierarchy-1.png" width="800"></img></p>
+<p><img src="images/fixture-script-hierarchies-1.png" width="600"></img></p>
<p>where each dependency represents one fixture script using <code>ExecutionContext#executeChild(...)</code> to execute another.</p>
<p>However, it could easily be refactored, for example as:</p>
-<p><img src="images/fixture-scenario-hierarchy-2.png" width="800"></img></p>
+<p><img src="images/fixture-script-hierarchies-2.png" width="600"></img></p>
<p>With this design there each fixture script takes responsibility for setting up its prerequisites, up to and including
running the <code>ToDoItemsDelete</code> teardown script.</p>