Jump to: navigation, search

Difference between revisions of "EDT:IDE Test Server Regression Testing"

Line 9: Line 9:
 
'''Dedicated services'''  
 
'''Dedicated services'''  
  
Verify a dedicated service is run on a test server for the main RUI Handler's project, not the service's project. To verify the right project is used, put the dedicated service in a separate project, but make sure it's on the EGL and Java build paths of the RUI project.
+
Verify a dedicated service is run on a test server for the main RUI Handler's project, not the service's project. To verify the right project is used, put the dedicated service in a separate project, but make sure it's on the EGL and Java build paths of the RUI project.  
  
Breakpoints in the service should be honored, because the test server is always in debug mode.
+
Breakpoints in the service should be honored, because the test server is always in debug mode.  
  
 
<br>  
 
<br>  
Line 17: Line 17:
 
'''REST services'''  
 
'''REST services'''  
  
Verify a REST service is run on a test server for the service's project, not the RUI Handler's project. To verify the right project is used, put the REST service in a separate project; it does not need to be on the EGL or Java build path of the RUI project.
+
Verify a REST service is run on a test server for the service's project, not the RUI Handler's project. To verify the right project is used, put the REST service in a separate project; it does not need to be on the EGL or Java build path of the RUI project.  
  
Breakpoints in the service should be honored, because the test server is always in debug mode.
+
Breakpoints in the service should be honored, because the test server is always in debug mode.  
  
Note: you neeed to use the workspace:// URI for the binding in your deployment descriptor, AND you need to configure the service to be deployed as REST in its default deployment descriptor file. Failure to do these steps will either cause the test server to not be used, or the test server will not be able to find the REST service.
+
Note: you neeed to use the workspace:// URI for the binding in your deployment descriptor, AND you need to configure the service to be deployed as REST in its default deployment descriptor file. Failure to do these steps will either cause the test server to not be used, or the test server will not be able to find the REST service.  
  
 
<br>  
 
<br>  
Line 48: Line 48:
 
<br> '''Database access'''  
 
<br> '''Database access'''  
  
TBD (include JNDI)  
+
In your service's deployment descriptor, add an SQL database binding and make sure it's configured to use JNDI. In your service function, add some code that looks up the binding to create an SQLDataSource, then run some SQL statements to verify it can connect correctly.
 +
 
 +
This database scenario should be run twice. Once with an Apache Tomcat runtime defined (you don't need to define the server, just the runtime at Preferences &gt; Server &gt; Runtime Environments), and once with no Apache Tomcat runtime defined. When it's defined, connection pooling will be used; when it's not defined, connection pooling is not used, and you will see a warning in the console about this case.
 +
 
 +
Another variation to add to SQL testing is to make your SQL database binding use application-based authentication (this is not the default). Do this both with and without Tomcat being defined.
 +
 
 +
If you have even more time to burn, you can run all these tests once with the binding referencing a connection profile, and once with the information hard-coded ("Specify connection information" radio button).<br>
 +
 
 +
All these tests should be successful without adding any JDBC jars to your project build paths.
 +
 
  
<br>
 
  
 
'''Deployment descriptors'''  
 
'''Deployment descriptors'''  

Revision as of 16:41, 5 March 2012

The following test scenarios should be run each release.

Read the top section of the main test server wiki page to understand some basics.  

Tip: To kill the test server so that you can try another scenario, either click the red terminate button in the console, or use the Debug view to kill the process.


Dedicated services

Verify a dedicated service is run on a test server for the main RUI Handler's project, not the service's project. To verify the right project is used, put the dedicated service in a separate project, but make sure it's on the EGL and Java build paths of the RUI project.

Breakpoints in the service should be honored, because the test server is always in debug mode.


REST services

Verify a REST service is run on a test server for the service's project, not the RUI Handler's project. To verify the right project is used, put the REST service in a separate project; it does not need to be on the EGL or Java build path of the RUI project.

Breakpoints in the service should be honored, because the test server is always in debug mode.

Note: you neeed to use the workspace:// URI for the binding in your deployment descriptor, AND you need to configure the service to be deployed as REST in its default deployment descriptor file. Failure to do these steps will either cause the test server to not be used, or the test server will not be able to find the REST service.


Prompting

The prompting preferences can be configured in Preferences > EGL > Test Server. Make sure to test each radio button with the below cases  

  • Classpath changes
    • Add or remove a jar or library to a project
    • Add or remove a project dependency on the Java build path
  • Hot code replace (HCR) failures 
    • Add or remove a global field
    • Change a function's signature
    • Don't worry about testing when HCR is unsupported by the JRE, this is extremely unlikely these days
    • Don't worry if you can't cause the "obsolete methods" failure


Other preferences

  • "Print debug messages in the console"
    • When disabled, the console is empty (or mostly empty) upon startup and you do not see tracing information during service invocation
    • When enabled, the console will have a ton of output on startup, and each service invocation will spit out a lot of tracing information.


Database access

In your service's deployment descriptor, add an SQL database binding and make sure it's configured to use JNDI. In your service function, add some code that looks up the binding to create an SQLDataSource, then run some SQL statements to verify it can connect correctly.

This database scenario should be run twice. Once with an Apache Tomcat runtime defined (you don't need to define the server, just the runtime at Preferences > Server > Runtime Environments), and once with no Apache Tomcat runtime defined. When it's defined, connection pooling will be used; when it's not defined, connection pooling is not used, and you will see a warning in the console about this case.

Another variation to add to SQL testing is to make your SQL database binding use application-based authentication (this is not the default). Do this both with and without Tomcat being defined.

If you have even more time to burn, you can run all these tests once with the binding referencing a connection profile, and once with the information hard-coded ("Specify connection information" radio button).

All these tests should be successful without adding any JDBC jars to your project build paths.


Deployment descriptors

TBD (include generated DD support)