Skip to content

12 Testing and coding

JackHeeley edited this page Jun 20, 2018 · 8 revisions

12 Testing and coding guidance

A number of examples and suggestions about coding practice are given elsewhere in this guidance. Here we want to emphasise the unity of coding and testing effort. Testing and coding are a single integrated process. There is no boundary.

This concept is known as test driven development. To exploit this concept, you need to embrace the idea of starting unit testing almost before you write a line of code. For this you need unit testing support and a test framework that delivers the test capability you expect (and is immediately available to use) so that testing doesn't end up being just one more thing in the way of getting the job started.

Microsoft tooling offers unit test frameworks that integrate well with their development tooling, and are aligned with future planning for development tooling. Unless one of the many plug-in alternatives is light-years ahead in features or capabilities, then its a no brainer to align with the test framework solution that will still be here in ten years. Other vendor test facilities I've seen can only claim slight advantages, and these come at the price of adopting a unique test dialect (vendor lock) in test code. App3Dev shows the microsoft unit test capability I have selected in action.

Only a few years ago, Visual Studio Developers, were indeed let down badly, and ended up with a legacy of unportable test code that could not be automatically upgraded. I hope and expect that this experience has readied the Microsoft unit test framework for the future, and that this situation is unlikely to repeat.

Test and Code Challenges

The challenges we face are:

  • Start unit testing at the same time that you start developing
  • Select a unit testing framework that will stand the test of time
  • Accommodate your answer to cross-cutting issues in unit tests

Test and Code Response

I suggest, and App3Dev demonstrates (with successes and limitations that you can evaluate for yourself) the following response:

  • Adopting Microsoft's unit testing framework, supplimented by utf8_assert.hpp
  • Writing and maintaining unit tests to prove new code, inclusive within the code development budget, giving 50% or better test coverage.
  • Including unit test results as part of check-in process
  • readable test code, uncluttered by text transformations, or other overheads.

Features

In practice (and with the help of App3Dev solution as a startpoint) unit tests can begin at the same time as your development begins, and won't be left behind by the development itself, or future changes in direction by development tool support.

  • Standard test framework and a simple treatment of cross-cutting issues leads to minimum delay in unit test setup at start of projects.
  • Writing unit tests on-the-go, means that a test deficit (or technical debt) doesn't accumulate.
  • Repeated application of tests leads to good regression testing of code
  • Prolonged use of tests leads to refinement and improvement of deliverable code, test code and test coverage over time

Limitations

  • Any unit test framework can become obsolete during project lifecycles
  • Alternatives to Microsoft's unit test framework live or die by offering feature advantages (Fair or not, I have chosen to disregard these as being marginal)
  • Test coverage in App3Dev is only typical of what can easily be achieved, and is not an indication of a satisfactory level of testing.

Clone this wiki locally