The bigger picture of application development

by Paul Kohler 31. March 2008 02:31

Last week I posted some notes of an Acceptance Testing Framework I started developing. My motivation for this is part of a larger project that is an attempt to "integrate" the typically disparate pieces of a project, things such as requirements, tests and issue tracking.

I find many companies use different tools/systems (I am counting a simple document as a "system" here, e.g. a requirements doc) for each part of the process and there is allot of duplication and converting going on. This in my eyes is a big waste of time and effort.  I am a huge fan of keeping things DRY (Don't Repeat Yourself), applying this to the full SDLC is difficult but I think possible and definitely beneficial. I see allot of importing, exporting, synchronisation and maintenance of data between these systems, even if just a document is used to produce requirements there is still allot of duplication and effort required by the developers for example to keep things in sync (for both the tests and the implementation).

Another area that bugs me is test data. A useful requirements document (I find) contains examples of what its explaining, so why not have an appendix of acceptance tests (or references to test data files)? These tests can be pushed through a testing engine of some sort and complete that difficult customer-developer loop. If a manager (or even a customer) is after a progress update, use the acceptance test results to give a real indicator instead of sitting in a meeting for 2 hours pouring over a Gantt chart making educated guesses.

Instead of a big word processing document why not access requirements via a system that allows you to see the history (diff) on a particular requirement, or link to its defects, or view pending change requests? Developers can book their development time against items that are linked to requirements - the implementation of 1 requirement can span many layers etc. Developers can make attach notes to requirements and tests.

As far as integration of existing systems is concerned, how about each area - requirement, test, timesheet - is accessed through a basic pluggable component. If the company has a bug tracking system already they can create an adapter that provides access to the data (I am thinking a simple CRUD interface), this would allow communication between existing systems.

And what about help documentation, screenshots of those screens!?

Just some thoughts ;-)

Tags:

Acceptance Test Framework

by Paul Kohler 27. March 2008 09:40

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!

 

Tags:

General

Finally imported my old blog posts!

by Paul Kohler 25. March 2008 08:25

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

 

Tags:

General

An NUnitForms testing strategy

by Paul Kohler 13. March 2008 00:27

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

 

Tags:

NUnitForms

Slight upgrade to Mini SQL Query

by Paul Kohler 4. March 2008 00:30
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...

Tags:

General

About the author

Paul Kohler, .net developer living and working in Brisbane, Australia...

Email me via the contact page or browse to the main PK Software site.