pk software dev blog

custom microsoft .net application development

27. March 2008 09:40
by Paul

Acceptance Test Framework

27. March 2008 09:40 by Paul

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!

 

25. March 2008 08:25
by Paul

Finally imported my old blog posts!

25. March 2008 08:25 by Paul

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  ;)

 

13. March 2008 00:27
by Paul

An NUnitForms testing strategy

13. March 2008 00:27 by Paul

These are basically some notes about to a GUI testing strategy I have adopted over the last year or so with NUnitForms. I am not going into what NUnitForms are etc here (because there an old NUnitForms post here) so I am assuming that you have at least some (or willing to get some) experience with the open source library prior to reading this post.

For a basic test fixture, typically you will inherit from the NUnitFormTest class overriding the Setup method:

[TestFixture]
public class FormXyzTests : NUnitFormTest{ 
 public override void Setup() 
 {
  new VesselDetailForm().Show();
  Application.DoEvents();
 }
 [Test] 
 public void CheckBla()
 {
  ButtonTester goButton = new ButtonTester("btnGo");
  LabelTester statusLabel = new LabelTester("btnGo");
  goButton.Click();
  Assert.That(statusLabel.Text, Is.EqualTo("Done."));
 }
}

When you test a button click you create a ButtonTester and initiate the Click method perform asserts and go home happy that your GUI is in a working state.

In the interests of refactoring GUI test that can quickly get bloated if you are not careful, I have ended up creating “form testers” that are in turn inherited by the test fixture. The form tester sets up a particular “scenario” and provides control testers and other helper methods through properties, for example:

public class FormXyzTester : NUnitFormTest
{
 public override void Setup()
 {
  VesselDetailForm frm = new VesselDetailForm();
  frm.Show();
  Application.DoEvents();
 }
 public ButtonTester GoButton
 {
  get { return new ButtonTester("btnGo"); } 
 }
 public LabelTester StatusLabel
 {
  get { return new LabelTester("lblStatus"); }
 }
}
 

Now the fixture inherits from the form tester and the tests are more readable.

[TestFixture]
public class FormXyzTests2 : FormXyzTester
{
 [Test]
 public void CheckBla()
 {
  GoButton.Click();
  Assert.That(StatusLabel.Text, Is.EqualTo("Done."));
 }
}

As other form specific related test helpers are required I add them to this base class. If needed, I also split this further with another base form tester class with common functionality. Other things I have included in these form testers are the message box responders, logging, even reporting and facilities to take screen shots of the application as its testing. These all help make for some very robust GUI testing classes.

PK Smile

 

11. March 2008 08:58
by Paul

Mini SQL Query and an SDK

11. March 2008 08:58 by Paul

OK, I'll call it an SDK but for now it's just the query tool and ZIP file with the API help and a plugin project template for VS.NET 2008. I am also working on a tutorial page for making a plugin.

Mini SQL Query is at version 0.9.48 now (added some plugin base class helper stuff) and getting pretty close to a version 1 release. I have been getting good feedback and have a few things left to improve before I am happy to call this thing "version 1".