There is an asymmetry that is interesting for people familiar with cryptography: as a developer, you can (re)create the production code if you have your test cases, but you cannot easily create the tests from your production code. So, the tests are a kind of collection of one-way functions — a trapdoor function; the implication is that the tests are perhaps more important than the production code itself.
There is also another asymmetry for people who have had to debug code (which is every developer in the world): developers using Test-Driven Development on a new project typically find that they tend to invoke a debugger less often than on a project without a test-first approach. Test-driven development, with robust version control, enables developers to revert back to the last version that passed all tests, and can be sometimes more productive than having to debug poor quality code.
With that preamble, let us delve into the practices of Test-Driven Development (TDD), and why we have built out the support for TDD in the Neo Blockchain Toolkit.Test-First
Testing does not have to dogmatically happen after the implementation; with TDD, testing goes first, reversing the legacy approach of developing the software and then testing it (typically, parts of it).
Why? The approach of writing a test that verifies the behavior of the expected feature, and then to write the code that implements the feature has two key implications; first, the test(s) are used as a compass to direct the developer to focus on the expected outcomes, and second, the tests are used a tracker to indicate how close the code to being completed.
What else? Further, with this approach, the developer then has a test or a test suite that can be repeatedly run to ensure that this feature and its behavior and outcomes work as expected even as other unrelated changes are made to the code ...