The bigger picture of application development

by Paul 3/30/2008 11:31:00 PM

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

Acceptance Test Framework

by Paul 3/27/2008 6:40:00 AM

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!

 

Finally imported my old blog posts!

by Paul 3/25/2008 5:25:00 AM

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

 

An NUnitForms testing strategy

by Paul 3/12/2008 9:27:00 PM

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

 

Mini SQL Query and an SDK

by Paul 3/11/2008 5:58:00 AM

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".

Slight upgrade to Mini SQL Query

by Paul 3/3/2008 9:30:11 PM

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...

Powered by BlogEngine.NET 1.3.1.0
Theme by Mads Kristensen

About the author

Paul Kohler Paul Kohler
A .NET software developer living and working in Brisbane, Australia.

PK Software
E-mail me Send mail

Calendar

<<  August 2008  >>
MoTuWeThFrSaSu
28293031123
45678910
11121314151617
18192021222324
25262728293031
1234567

View posts in large calendar

Authors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008