TestingGuidelines: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
No edit summary
Line 14: Line 14:
* How to test abstract classes?
* How to test abstract classes?
* Can we create a system that checks for the existence of a test file for every concrete class? This would be a great place to start to improve coverage.
* Can we create a system that checks for the existence of a test file for every concrete class? This would be a great place to start to improve coverage.
* When should a new "test prefix" be started? By adding tests to a list like this:
CREATE_TEST_SOURCELIST(''Array''Tests ArrayCxxTests.cxx
they show up when running ctest as:
Start 33: ''Array''-TestArrayBool

Revision as of 23:58, 22 August 2010

  • When adding a new concrete class, a test should also be added in
...VTK/Package/Testing/Cxx/
  • The name of the file for the test should be ClassName.cxx where the name of the class is vtkClassName.
  • Each test should call several functions, each as short as possible, to exercise a specific functionality of the class. 1,000 lines in main() is very hard to maintain...
  • The "main()" function of the test file must be called TestClassName(int, char*[])

Questions

  • Do we bother covering deprecated classes?
  • Is there a way to mark deprecated classes as deprecated so they do not show up on the coverage dashboards?
  • What is our target coverage percentage? 70%?
  • How to test abstract classes?
  • Can we create a system that checks for the existence of a test file for every concrete class? This would be a great place to start to improve coverage.
  • When should a new "test prefix" be started? By adding tests to a list like this:
CREATE_TEST_SOURCELIST(ArrayTests ArrayCxxTests.cxx

they show up when running ctest as:

Start 33: Array-TestArrayBool