Jump to: navigation, search

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

Line 9: Line 9:
 
'''Dedicated services'''  
 
'''Dedicated services'''  
  
TBD
+
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.
  
 
<br>  
 
<br>  
Line 15: Line 17:
 
'''REST services'''  
 
'''REST services'''  
  
TBD
+
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.
  
 
<br>  
 
<br>  
Line 48: Line 54:
 
'''Deployment descriptors'''  
 
'''Deployment descriptors'''  
  
TBD (include generated DD support)
+
TBD (include generated DD support)  
 +
 
 +
[[Category:EDT]]

Revision as of 16:35, 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

TBD (include JNDI)


Deployment descriptors

TBD (include generated DD support)