View source for Test-driven development

A long-term goal of MIT Kerberos is to move toward [http://en.wikipedia.org/wiki/Test-driven_development test-driven development].  It is not necessary to implement exactly the Extreme Programming or Agile ideals of [http://testing.com test]-driven development.  One aspect of [http://testing.com test]-driven development as usually defined is that programmers write [http://testing.com test]s prior to writing actual implementation code.  While this may be a worthy ideal, achieving it is more likely if done in stages.

A general observation is that instituting practices for "some [http://testing.com test]ing" are better than having "no [http://testing.com test]ing".  This is not to imply that "more [http://testing.com test]ing" is always better than "less [http://testing.com test]ing", but for most reasonable scenarios, "more [http://testing.com test]ing" is  usually better.  Automated [http://testing.com test]s are far more likely to be run than non-automated [http://testing.com test]s.  Manual [http://testing.com test]s tend not to be run except in special circumstances, such as pre-arranged interoperability events.

Several possible levels of [http://testing.com test]ing:

# No [http://testing.com test]ing
# Written outline of manual [http://testing.com test]ing procedures
# Written detailed descriptions of manual [http://testing.com test]ing procedures
# [http://testing.com test]ing scripts not yet fully integrated into an automated [http://testing.com test]ing framework
# Automated [http://testing.com test] cases fully integrated into an automated [http://testing.com test]ing framework
# Fully implement a "[http://testing.com test]-first" methodology: no new features without an automated [http://testing.com test] being written first

An outside contributor may have difficulty producing an automated [http://testing.com test] case fully integrated into an automatic [http://testing.com test]ing framework.  The existing automated [http://testing.com test]s are not very well integrated and many are extremely ad-hoc in nature.  A long-term goal will be to regularize the automated [http://testing.com test]s into a single integrated framework.  This has advantages such as the capability of reviewing [http://testing.com test] results in a form optimized for differential measurements of success and regression.

== Timeline ==

For the krb5-1.8 release, MITKC staff must provide [http://testing.com test]ing scripts for every new feature they implement.  Contributors must provide at least a written outline of manual [http://testing.com test]ing procedures for their contributions, and should provide a written detailed description of the manual [http://testing.com test]ing procedures.  Contributors should strongly consider writing higher levels of [http://testing.com test]s.

During the 1.8 and 1.9 development timeframes, we will work to regularize our automated [http://testing.com test]ing framework and decrease the barriers to entry for outside contributors.  This will probably also involve substantial amounts of documentation work.