Open mosherubin opened 2 years ago
Considering the numerous different functional areas in the engine (e.g., tokenization, iterating the token list, verifying lexer member functions and fields), we might want to have a separate unit test source file for each area, rather than lumping them all together into a single source file. Tests should be inserted in the appropriate unit test source file. All unit test source files should then be imported into nsiqunittest/nsiqcppstyle_unittest.py
.
Background
NsiqCppStyle is a serious Open Source software project, intended for general use. Every time a change is made to the engine code, there is a real risk of breaking the existing implementation and/or features. NsiqCppStyle requires high-quality and reliable regression tests to ensure that changes to the existing engine code base won't affect the existing features of the project.
As expected of a well-designed product, NsiqCppStyle has a dedicated unit/regression test source file:
nsiqunittest/nsiqcppstyle_unittest.py
. The file defines a classunitTest
with member functions, each one representing a unit/regression test. This script file currently has a small number of tests:testIgnore
functionfinal
token is ignoredoverride
token is ignorednoexcept
token is ignoredGetNextToken
GetNextTokenSkipWhiteSpaceAndComment
test3
with console level set toconsole.Level.Verbose
It is clear that these tests are the proverbial "tip of the iceberg", and that many more such tests should be added to ideally provide complete coverage of internal engine code.
Request
Effort should be invested to write as many targeted unit/regression tests for NsiqCppStyle internals as possible. As more people submit code changes, having a rich set of regression tests will give us the confidence needed to make changes without breaking the existing code base.
The writing of such tests should be an ongoing task: every time any contributor (or the maintainer) touches a section of NsiqCppStyle engine code, time should be allocated for enriching the set of unit/regression tests, all related to the section/features modified.
Similarly, while implementing a new feature, should a contributor break the product during development, s/he should stop and write the necessary unit/regression tests to never allow that break to happen again.
IMHO, this should be a high-priority task as soon as the current pull requests have settled and are merged.