120 likes | 245 Vues
This document outlines a strategy for improving unit testing in geWorkbench by adopting Model-View-Controller (MVC) design principles. It details testing approaches for the Model and Controller using JUnit while employing manual system testing for the View component. It highlights the existing structure of geWorkbench, identifying components that adhere to and deviate from MVC principles. Recommendations for refactoring certain components to enhance testability and a framework for organizing test cases are included, along with practical testing guidelines to ensure comprehensive coverage.
E N D
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.
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!
Components that are MVC • Hierarchical Clustering • Support Vector Machine • ARACNE
Components that are Almost MVC • SOM Clustering • All file parsers • All analyses, normalizers and filters (reference their GUI forms directly to get parameters)
Components that are not MVC • Reverse Engineering • Marker Annotations • Gene Ontology • GSEA • Sequence Retriever • Synteny • Promoter Panel • Sequence Alignment Panel
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).
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.
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/