Introduction

The question of how to involve unit testing in this project has come up. There are three different testing methodologies that could be used. These are:

• Test driven development
• Tests written after each feature
• No testing

Test driven development

This methodology consists of first writing tests, then implementing the features to ensure the tests pass.

The advantage of this is it ensures the program is thoroughly tested, enures a significant reduction on defect rates and may improve the quality of the code

the downside of this technique is that it requires a significant increase in initial programing effort.

Tests written after each feature

This methodology re requires less effort that TTD but results in less stringent tests. It ensures that future features do not break already implemented features.

No testing

Not using tests means that the project can not benefit from the great benefits of testing, but also requires no extra effort.

Conclusion

Due to the current very small scale of the project, and the developer's lack of skills in testing, TTD is a bit overkill and would slow down the project considerably, with much more time spent writing tests than writing code.

With the scale of the project, not using unit tests is feasible, but in order to increase the dev team's experience of testing, and to make the program more scalable, testing after each feature would be the best option. For the purposes of this project, a "feature" for testing will be defined as one sprint/iteration.

supplement: GUI

Gui testing is more complex. The team has decided to follow the methodology of moving the logic of GUI code to separate functions that can be tested, and replying on manual testing to make sure GUI works