I have started work on an acceptance test framework with concepts similar to FIT. Actually the acceptance testing is just part of a bigger picture that I am building up. I have a very integrated vision for requirements, their tests, code generation etc. I have not been able to get customers using systems like FIT, I think they find it too academic or something but would rather stick with the traditional methods that (seem) to work. Perhaps tolerate is a better word!

The acceptance tests for now are in the form of business rules as data in a spreadsheet, such as:

Pay Type  Amount  Overtime Hours  Result

Hourly    25.85   1               1056.00

Hourly    10      0               400.00

Daily     500     0               2500.00

The developers provide a “test view” that takes the data and processes it, the “Result” is then compared and a report produced. Business rules are extracted and documented as you work through examples. The acceptance tests then become regression tests to ensure no existing functionality is broken by further development.

public class PayCalcTestView : ITestView

{     

	private PayCalc _calculator;

	public int Overtime_Hours;

	public PayType Pay_Type;

	[AcceptanceTestOutput]public decimal Result;    

	public PayCalcTestView()

	{

		_calculator = new PayCalc();

	}

	public void ExecuteTest()

	{

		Result = _calculator.CalculatePay(Pay_Type, Amount);

	}

}

You can use fields or properties and an output variable (the one used for camparison) is marked with an attribute.

I am also looking at applying it to simple GUI testing for Windows Forms apps and possibly web sites.

It's the kind of project I would like to full time on for a couple f months!

 

I had trouble getting the Import tool to work so quickly rolled my own quick hack. It got most of it done - just a little cleaning left to do (the uploaded files/pics).

I'll post the code when I am done - nothing special but may prove helpful  ;)

 

Last week I slipped an update in to Mini SQL Query - version 0.9.37.
Just minor fixes, updates, a quick start help page and I added a "Templates" tool window plugin...

I was working with the new MS MVC framework but with express, I used Lazycoders post as a helper to what lead to this template. I have put together a simple C# project template for Visual Web Developer 2008 Express Edition. Just dump it into your

  "(my docs)\Visual Studio 2008\Templates\ProjectTemplates\Visual Web Developer"

folder and choose “new website” etc (may need to restart the IDE to pick up the files).

It puts together the basic structure using the "App_Code" restriction in the express edition of the IDE (well, and some others...)

 

There is also a simple “view page” item template, drop this into

  "(my docs)\Visual Studio 2008\Templates\ItemTemplates\Visual Web Developer"

I did not worry about the controller (simgle page + simple change etc)...

Merry Christmas! PK :-)

 

Files:

• WebDevMvcAspNetSite.zip (8.73 KB) (C# project template)
• MvcViewPage.zip (2.27 KB) (C# item template)

It's common practice for developers to make small "TODO" notes in code as they work for themselves or others to clarify at some time...

// TODO: confirm this business requirement...
// TODO: make this better!
// TODO: bread, butter, eggs and milk...

Issues can arise when the TODO's are not taken care of for whatever reason or get lost in the mayhem of meeting deadlines. A worst case scenario could arise when there is a production defect for an obscure situation and the maintenance programmer finds something like this:

// TODO: Not sure if there are any more response codes for this one, check before release.

Opps! Now that's expensive.
Now I am not saying this is good or bad (!) practice - but what I have started to do within my team is create either a failing or ignored unit test (depending on the importance) marking what would normally be an innocent "TODO" item. The unit test stays in the build as either a fail or ignore and does not drop off the radar.

[Test]
public void Need_to_confirm_foo()
{
  Assert.Fail();
}

Or...

[Test]
[Ignore("Confirmation required from the business")]
public void A_foo_only_has_a_bla()
{
}

It's much harder to miss a bunch of ignored or failing unit tests before that production release than some well hidden TODO comments!

 

Scott Guthrie talks about Microsoft releasing the .Net framework source code later this year.
A very good move by Microsoft I think :-)

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

Make that version 1.0.0.3!

I did not quite get this feature into the previous version and just posted the updates in case I got busy.

The big (and very useful) change for build 3 is that you can "paste" unit test code into the tool and the phrases will be extracted - if they use underscores and the code is C# (sorry, minor bug, I'll fix that shortly!) In practice I have found the underscore styke far more readable.

For example, if you have the following unit test code, copy it to the clipboard...

namespace Tests
{
    [TestFixture]
    public class PersonEntityTests
    {
        [SetUp]
        public void TestSetUp()
        {
            // ...
        }
        
        [Test]
        public void A_method_will_be_extracted_from_the_clipboard()
        {
            // asserts etc
        }
    }
}

...and use the new "Paste beaviours from clipboard" menu option (or ALT+F5) and you get the method name extracted.

The full round trip. Whe you want to continue working on a unit test class you can use this feature to get the current context of the testing... have fun! PK :-)

  http://www.pksoftware.net/BehaviourToUnitTest/

---

Quick note - now at v1.0.0.2 - the main changes are:

• The use of the ICSharp.TextEditor for better editing
• The defaults are C# with the underscore style
• A few more word substitutions by default

Enjoy!

I have uploaded a small development tool that I put together recently, its called "Behaviour to Unit Test". Basically it converts code functionality from plain sentences (or stories) into unit test stub code. You could also think of it as a cure for TDD writers block!

For an example of the usage, use the Generation -> Fill out example menu option and hit Convert. Basically it takes a set of plain language behaviours for an object such as "person":

• Check that the default values of all string properties are empty
• The ToString method renders the first and last names
• If the date of birth is null, calculate age will return -1
• If the date of birth is not null, calculate age will return a value

...and converts them into something like:

using System;
using NUnit.Framework;
using NUnit.Framework.SyntaxHelpers;

namespace Tests
{
    [TestFixture]
    public class PersonEntityTests
    {
        private PersonEntity person;
        
        [SetUp]
        public void TestSetUp()
        {
            person = new PersonEntity();
        }
        
        [Test]
        [Ignore("Currently only a unit test stub")]
        public void CheckThatTheDefaultValuesOfAllStringPropertiesAreEmpty()
        {
        }
        
        [Test]
        [Ignore("Currently only a unit test stub")]
        public void TheToStringMethodRendersTheFirstAndLastNames()
        {
        }
        
        [Test]
        [Ignore("Currently only a unit test stub")]
        public void IfTheDateOfBirthIsNullCalculateAgeWillReturnMinus1()
        {
        }
        
        [Test]
        [Ignore("Currently only a unit test stub")]
        public void IfTheDateOfBirthIsNotNullCalculateAgeWillReturnAValue()
        {
        }
    }
}

There are C# and VB.NET templates for now. Check it out:

  http://www.pksoftware.net/BehaviourToUnitTest/

My intention is to keep the tool small and simple. The main thing I want to add at the moment is some load/save functionality and drop in the ICSharp.TextEditor for more friendly editing...

This is just a quick heads up to say that I think the Castle Project rocks!

I have been using it allot of late especially Active Record. I'll blog more detail later but it's what I have been looking for all these years! Many time I have implemented simple subsets of the functionality that Castle provides to help get the job done. Castle wraps up all those funky framework fragments and more with a great "action pack" flavour to it in the form of Mono Rail (i.e. 'ruby on rails' for .Net)

Very cool  ;-)

Just a quick note that could drive you completely mad if you were not aware...

If you are using NUnitForms for testing your GUI and have code in the forms "Shown" event, it will not run unless you follow the Form.Show call with Application.DoEvents(), see sample code below

This example is just a Label (label1) dumped on a Form with the Load and Shown events updating the label with the respective event text:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace NUnitFormsDemo1
{
    public partial class ShownTestForm : Form
    {
        public ShownTestForm()
        {
            InitializeComponent();
        }

        private void ShownTestForm_Load(object sender, EventArgs e)
        {
            label1.Text = "Load";
        }

        private void ShownTestForm_Shown(object sender, EventArgs e)
        {
            label1.Text = "Shown";
        }
    }
}

Here is some sample NUnitForms test code, the first test asserts that after the Form.Show call the label text is "Load" and the second test shows that the label text is "Shown".

using System;
using System.Windows.Forms;
using NUnit.Framework;
using NUnit.Extensions.Forms;

namespace NUnitFormsDemo1.UnitTests
{
    [TestFixture]
    public class TestFormShownIssue : NUnitFormTest
    {
        [Test]
        public void TestFormShow()
        {
            ShownTestForm frm = new ShownTestForm();
            LabelTester label1Tester = new LabelTester("label1");
            frm.Show();
            Assert.AreEqual("Load", label1Tester.Text);
        }

        [Test]
        public void TestFormShowWithDoEvents()
        {
            ShownTestForm frm = new ShownTestForm();
            LabelTester label1Tester = new LabelTester("label1");
            frm.Show();
            Application.DoEvents(); // allows the 'Shown' event to fire
            Assert.AreEqual("Shown", label1Tester.Text);
        }
    }
}

 

I will take an educated guess that this is due to the GUI message pump etc.

In general if I come across this any of this type of unexpected behavior with NUnitForms I will try a DoEvents before tearing my hair out.