NUnit


Philosophy
First and foremost, we have done our best to insure that this program was developed test-first. As such we will accept no code changes without associated tests. As for bug fixes we plan to follow the procedure that we write a failing unit test first and then fix it. In this fashion, the number of tests that we have will grow over time. Lastly, if a change breaks an existing test it is the responsibility of the person making the change to first understand the ramification of the change and either fix the test or alter the modification that caused the problem. That said, if you are interested, so are we, please help make NUnit the best xUnit tool in any language.

NUnit Development Guidelines
Our goal is to have as many people participate in the development as possible. However, the normal random development of open-source often leads to projects that stall and then die. Too often these projects are technology driven and once the technical problem has been solved the developer loses interest. We do not want this to happen to NUnit. So we are attempting to put in a minimal amount of process to insure that the development moves forward in a way that the community chooses.

Feature Selection/Prioritization
It is incumbent on all users to suggest new features that would be useful and to participate in the prioritization of the features. It is your program after all, why not try and make it better. These requests should be sent to nunit-developer@lists.sourceforge.net. The requests should be more than one line of text. They should be accompanied by additional information, such as code examples and possible suggestions on implementation. They should also include pros/cons of why this should be part of NUnit.

Note: There is a balance that needs to occur for the development of NUnit. We could just allow NUnit features to emerge out of the feature requests and the product would be completely driven by the community. On the other hand NUnit is a unit-testing tool for on the .NET platform. So, overall the direction of new development must exist with the confines of this being a unit testing tool for .NET.

Once a feature request has been submitted it will be consolidated with other like feature requests and added to the list of features that have been suggested. There may be an initial poll to determine if the feature should even be prioritized.

Since we plan on doing two week iterations these feature request may be split up in order to be accomplished within an iteration. Based on developer availability every two weeks the features that are desired the most by the community will be the ones that are worked on. We will be developing a poll to be implemented on this site to facilitate this. 


Iteration Development
An iteration begins with an iteration planning meeting. At this meeting all current bugs are reviewed along with the current highest rated features. Based on the amount of developer availability certain items will be committed to the iteration.

If you are interested in participating in an iteration send a message to nunit-developer@lists.sourceforge.net. Along with your email please indicate the amount of time that you capable of spending within the next iteration and given a current scan of the bugs and features what you would most like to work on. If you would like to work on something that is not on the iteration list you will need to submit a feature request and have it be prioritized like everything else.

As part of committing to work on features we would like developers to break their work up into tasks. A task duration should be no longer than 1 or 2 days. Upon completion code should be checked into the source code control system. The code will be reviewed by the one of the Admins for adherence to the coding standard and other coding guidelines.


Coding Guidelines
Test-Driven Development. This is non-negotiable. There will be no code that is accepted without associated tests. Also, we expect that Refactoring is part of your everyday activities so if there is a need to refactor do it.

For bugfixes there must also be an associated test which exposes the bug. This allows the tests to increase over time and the overall coverage of the tests improves. There may be times when it is not possible to have a test. In these cases please let us know the circumstances and we will decide if there is a way to test a particular item.

It also the goal that any current download from the source code control system is releasable. Therefore, it is incumbent upon you to insure that you run all the tests on code prior to check-in. Also, once the files are checked-in you should download the current files  into a new folder recompile it and run the tests. This verifies that what is in the source code control system is at least no worse than it was before you started.


Code Samples
The following is a code sample that demonstrates the style in which we want code to be written for the project.

namespace NUnit.Framework
{
  using
System;

  /// <summary>A set of Assert methods.</summary>
 
public class Assertion
  {
    ///
<summary>
    ///
Asserts that a condition is true. If it isn't it throws
   
/// an <see cref="AssertionFailedError"/>.
   
/// </summary>
    ///
<param name="message">The condition, if false</param>
    ///
<param name="condition">The evaluated condition</param>

    static public void Assert(string message, bool condition)
    {
      if
(!condition)
        Assertion.Fail
(message);
    }
  }
}

 


Copyright © 2002-2004 James W. Newkirk, Alexei A. Vorontsov. All Rights Reserved.
|