Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EclipseLink/Development/Testing/StrawManProposal"

([http://en.wikipedia.org/wiki/Hollywood_Principle The Hollywood Principle])
([http://en.wikipedia.org/wiki/Hollywood_Principle The Hollywood Principle])
Line 40: Line 40:
 
There are two things injected by the <tt>TestContextRunner</tt>:
 
There are two things injected by the <tt>TestContextRunner</tt>:
 
# Properties
 
# Properties
#* found in the <tt>ntf.xml</tt> file in the user's home directory
+
#* found in the <tt>ntf.xml</tt> file in the user's home directory \\
#** the name and location of the <tt>ntf.xml</tt> file can be altered by the Java System properties <tt>-Dntf.file</tt>=''some_other_file.name'' and <tt>-Dntf.dir</tt>=''some/directory/path''
+
#***
+
 
<pre>
 
<pre>
 
<?xml version="1.0" encoding="UTF-8"?>  
 
<?xml version="1.0" encoding="UTF-8"?>  
Line 51: Line 49:
 
   </properties>
 
   </properties>
 
</pre>
 
</pre>
 +
#** the name and location of the <tt>ntf.xml</tt> file can be altered by the Java System properties <tt>-Dntf.file</tt>=''some_other_file.name'' and <tt>-Dntf.dir</tt>=''some/directory/path''
 
#* Java System properties  
 
#* Java System properties  
 
# User-defined context object
 
# User-defined context object

Revision as of 17:22, 22 November 2007

From the EclipseLink DevMeeting 071017, create a straw-man proposal for a new consolidated testing framework

New Testing Framework

  • based on JUnit4 - Why?
    • JUnit3 is at end-of-life
    • Eclipse IDE has built-in support for JUnit4 tests
    • while various testing frameworks have been extended, JUnit4 is extensible by design

Looking at requirements from MOXy/SDO/DBWS/JPA, this is what we've got so far ...

The Hollywood Principle

Don't call us, we'll call you The basic idea is to de-couple the tests from their resource setup requirements that currently are handled through Java inheritance (not the best for component re-use). The NTF instead injects the resource into a tagged context variable owned by the test. Setup for the context is done in a separate class with its own requirements for composition/aggregation/inheritance.

// javase imports
import java.util.Properties;

// JUnit imports
import org.junit.Before;
import org.junit.BeforeClass;
import org.junit.Ignore;
import org.junit.Test;
import org.junit.runner.RunWith;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertTrue;

// ntf imports
import org.eclipse.persistence.ntf.TestContext;
import org.eclipse.persistence.ntf.TestContextRunner;
import org.eclipse.persistence.ntf.TestProperties;
import org.eclipse.persistence.ntf.Context;

@RunWith(TestContextRunner.class)
public class ASetOfSimpleTests {

    @TestProperties public static Properties properties;
    @TestContext(tag="context") public static Context<Object> context;

There are two things injected by the TestContextRunner:

  1. Properties
    • found in the ntf.xml file in the user's home directory \\
<?xml version="1.0" encoding="UTF-8"?> 
<ntf>
  <properties>
    <property
      name="easy_as">pie</property>
  </properties>
      • the name and location of the ntf.xml file can be altered by the Java System properties -Dntf.file=some_other_file.name and -Dntf.dir=some/directory/path
    • Java System properties
  1. User-defined context object
    • an external factory constructs an object that implements Context, providing a simple API to look up objects by name:
public interface Context<V> {

    public boolean containsObject(String objectName);

    public V getObject(String objectName);

}

Back to the top