1 / 12

Unit Testing in geWorkbench

Unit Testing in geWorkbench. Ideally, we would like a Model-View-Controller design for framework and all components. In MVC, the View and the Controller both depend on the Model, and the View also depends on the Controller.

vlad
Télécharger la présentation

Unit Testing in geWorkbench

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Unit Testing in geWorkbench

  2. Ideally, we would like a Model-View-Controller design for framework and all components. • In MVC, the View and the Controller both depend on the Model, and the View also depends on the Controller. • This allows us to do unit testing on the model and the controller without having to deal with the View.

  3. MVC Diagram

  4. Desired Testing Strategy • Model – Unit testing with JUnit. • Controller – Unit testing with JUnit. • View – Manual System testing by QA staff. • However, geWorkbench is not MVC!

  5. geWorkbench is M(VC)

  6. Components that are MVC • Hierarchical Clustering • Support Vector Machine • ARACNE

  7. Components that are Almost MVC • SOM Clustering • All file parsers • All analyses, normalizers and filters (reference their GUI forms directly to get parameters)

  8. Components that are not MVC • Reverse Engineering • Marker Annotations • Gene Ontology • GSEA • Sequence Retriever • Synteny • Promoter Panel • Sequence Alignment Panel

  9. Steps to Make geWorkbench More Testable • Refactor analyses, normalizers and filters so that they are properly MVC. • Refactor progress bars and other minor Swing interaction out of file parsers and analyses. • Address those components that are not even remotely MVC (either by large refactors or by rewrites).

  10. Testing Framework • In the main directory, and in each component directories, there is a test source directory. Put all test cases here. • Test cases should extend junit.framework.TestCase and have the word Test at the end of the classname. • The ant task run-junit runs all tests and puts results in to a report.

  11. Testing Guidelines • Consider “normal” input as well as degenerate input. • Try to ensure that your testing “splits” each if-statement (coverage). • Don’t just check for exceptions, compare output to known correct answers. • Build up utilities if needed to repeatedly check similar conditions. • The Apache Commons Collections have excellent testing that is worth studying: http://www.apache.org/dist/jakarta/commons/collections/source/

  12. The End

More Related