What Test-Driven Scoffolding (TDS) does...
TDS is a slightly relaxed version of Test-Driven Development (TDD) for C# projects, providing templates for drivers of function members, such as methods or indexers, and (optionally) generating test reports.
below for current status.)
When you develop a new function member or modify an existing one, you must often also write some additional calling code that exists only to exercise the code that you are developing -- which is what you're really interested in. The software provided on this site (as C# source code) is intended to help you quickly produce this exercising or calling code, giving you a template that you may copy and use for this purpose, instead of writing custom code each time. It is intended to be easily modified to provide inputs to your code, to inspect the results, and to display a report of those results.
Basic instructions and examples are provided in the downloadable C# source-code file. The TDS code can support building a new function member (such as a method), then, after the new code is functional, the TDS code can easily be removed without affecting the new function member, in a manner similar to removing the scaffolding on a completed building.
The C# code provided in this site can be downloaded and used in a new or existing project, then removed (almost without a trace) when it is no longer needed. The code in TDS.cs is in the public domain and is intended to be modified in any way you might find useful, without restriction.
The TDS code may be used in any of the following ways:
- The TDS templates may be used as drivers for use in debugging function members that you develop, without involving any unit-testing activity. For example, XSLT files or RegEx patterns can be tricky to develop, and TDS can help you exercise them by feeding them example inputs and observing the results.
- The TDS built-in test facility may be used, instead of NUnit or Visual Studio Test, in conjunction with test methods based on the TDS templates, to generate unit-test reports on the Console. These reports can be saved for later comparison to verify that no significant change in behavior has occurred.
- NUnit or Visual Studio Testing may be used to generate reports of unit tests based on the TDS templates. (TDS test methods can run unchanged with either NUnit or Visual Studio Test.)
If you notice any problems with code or documentation, please post a comment so that corrections can be posted.
The current release has been tested with Microsoft Visual Studio Express 2013 for Windows Desktop
(as well as VS 2012 and VS 2010). It may work with earlier versions but has not been tested with them.
Design goals included making TDS usable in a minimal development environment, such as with the free-of-charge Express versions of Visual Studio. TDS may also work well in a command-line-only development environment, but hasn't been tested that way (and editing the code outside of Visual Studio could be a bear).
Why is this not a Wizard?
This code is distributed exclusively as C# source code, rather than as a Wizard or in some other more automated form, to allow you as much flexibility as possible in incorporating it into your projects. Also, you can easily examine all of the source code to determine that it is safe to use.
New version 1.6 is available
The Visual Studio 2012/2013 version of the code is available on the Downloads tab. Please post any comments or requests in either "DISCUSSIONS" or "ISSUES" on this site, to help me decide what kinds of examples to add to the instructions. The Version 1.4 User's Guide is still usable and contains more detailed instructions and examples than are included in Version 1.6, though some details may have changed.
Possible alternate instructions
Note: Instead of advising users to disable test-related exception notifications (beginning around line 3809 of TDS.cs), I considered simply suggesting that whenever a dialog box pops up to report one of the listed exceptions, clear the "Break when this exception type is user-unhandled" check box. This is probably easier to do, but, since the exceptions pop up at possibly unexpected times, I thought that taking care of all of them at the beginning was a cleaner way to handle them. (If I publish another version, I may include both sets of instructions, giving you a choice of ways to disable them.)
Why is this still "Beta"?
I shall continue to characterize this software as a "beta" version until I have sufficient feedback as to its utility on a development project that is not of my own design (you are invited to use the "Discussions" tab on this site to post such feedback).