Category Archives: Development

TDD

When Tests Get Hard

I attended Charlie Poole’s When Tests Get Hard session.

The first thing that Charlie said summed XP up for me: “lots of little bits that I’d being doing, but brought together”

Why is testing/TDD hard? A quick poll of the attendees revealed

  1. no obvious programming interface
  2. set up time too great, especially for databases
  3. code in containers or managed by containers can prove difficult to work with
  4. “Graphical User Interfaces (GUIs) either look good or they don’t”, another fine quote from Alan!

Charlie followed it up with: testing connected sets of objects is hard because:

  1. tests become dependent upon one another
  2. objects have to be put into a known state
  3. it’s hard to figure out what failed

We went on to look at why GUI testing is hard.

GUIs are hard to test because there is tight coupling to other parts of the application, including the business logic. The solution to this is to separate the business logic from the UI, to use interfaces to permit substitution and factories to create business objects. This ran into an interesting discussion regarding the use of interfaces: some folks have argued that using interfaces isn’t the simplest and most expressive “thing”. Charlie believes that they are, on the grounds that they make it clear that a class has a capability. A similar discussion can be found here.

GUIs are hard to test because there is one large program handling all user interaction. Charlie’s recommendations revolved around using separate classes for UI logic and for validation. He also recommended the creation of smart controls (NUnit’s status bar being an example of such a thing – if you have NUnit installed, take a look here: C:\Program Files\NUnit 2.2\src\uikit). The key takeaway from this point was that the forms know too much about the objects that are dropped on them.

GUIs are hard to test because the design is driven by the IDE. Today’s modern IDEs will let you create a form, drop a button on it, double click on the button and write code for the button click. Granted, if you are doing the simplest thing, this is the right place for code, but in the long term it’s the wrong place for code (sure, you’d refactor it out, right?) We should resist the temptation to insert code into a UI just because the UI makes it easy. We should split code into two parts, presentation and behaviour (the use of partial classes and inheritance can help with this). Charlie recommend that we all read or re-read Mike Feather’s The Humble Dialog Box.

GUIs are hard to test because of technical issues of the platform. Charlie reiterated the need to be clear about what testing is needed, i.e. don’t test the platform (except to learn how the platform can help you with your testing), or put other way “don’t test other people’s stuff”

I liked Charlie’s “The Hardness Paradox” which basically stated that if something that is hard to test, it has to be a good thing. This will force us to look more deeply at how are applications are designed, with a view to making them easier to test. Humoursly, we compared this to a bang on the head – were it not for the fact that it hurts, we might keep doing it! Why should we shy away from difficult activities? We’ve cracked TDD for [elementary] classes, now we’re moving on to the next stage: testing the UI, the database, the web service, etc.

Quote for the day:

“If you don’t talk to the customer, the details don’t come up” – Charlie Poole, Edinburgh, 30th June 2005

Lastly, I also had the luxury of joining Charlie, Clarke, Barry and Peter for dinner (Colin joined in but didn’t eat!)

(Oh, and NUnit 2.4 is under development! Can’t wait!)

.net

Excel Interop – killing Excel.exe

42 Comments

This posting over at ScottishDevelopers got me thinking, especially since I’ve used Excel and Word from a number of Delphi applications over the last eight years. I have come across this problem in the past (Win32), so I thought it should be fairly easy to chase.

After a bit of research, The Code Project suggested that the Excel process be killed off through code:

Process[] pProcess; 
pProcess = System.Diagnostics.Process.GetProcessesByName("Excel");
pProcess[0].Kill();

Well, that would work, but it might kill off the wrong instance, or kill off the user’s precious ‘expenses’ spreadsheet instead of the one we created.

To help me trace the problem, I used the following code:

using System.Diagnostics;
using System.Runtime.InteropServices;

Excel.Application	excelApp = null;
Excel.Workbook	excelWorkbook = null;
Excel.Sheets	excelSheets = null;
Excel.Worksheet	excelWorksheet = null;
Excel.Workbooks	excelWorkbooks = null;

private void button3_Click(object sender, System.EventArgs e)
{
  excelApp                 = new Excel.ApplicationClass();
  excelApp.Visible  = true;
  excelWorkbooks   = excelApp.Workbooks;
  excelWorkbook = excelWorkbooks.Add(System.Reflection.Missing.Value);
  excelSheets = excelWorkbook.Worksheets;
  excelWorksheet = (Excel.Worksheet)   excelSheets.get_Item(1);
  excelWorksheet.Cells[1,1] = "42";
}

private void button4_Click(object sender, System.EventArgs e)
{
  excelWorkbook.Close (false, System.Reflection.Missing.Value,System.Reflection.Missing.Value) ; 

  excelWorkbooks.Close();
  excelApp.Quit();

  Marshal.ReleaseComObject(excelWorksheet);
  Marshal.ReleaseComObject(excelSheets);
  Marshal.ReleaseComObject(excelWorkbooks);
  Marshal.ReleaseComObject(excelWorkbook);
  Marshal.ReleaseComObject(excelApp);

  excelWorksheet = null;
  excelSheets = null;
  excelWorkbooks = null;
  excelWorkbook = null;
  excelApp = null;

  GC.GetTotalMemory(false);
  GC.Collect();
  GC.WaitForPendingFinalizers();
  GC.Collect();
  GC.GetTotalMemory(true);
}

This code creates an Excel application, populates it, then lets us close it. Invoking the button3 code creates it, button4 removes it.

Now, without the calls to the garbage collector, excel.exe hung around if the code behind button3, button4, button3, button4 is invoked.

In the short-term, I would suggest adding the additional calls to the garbage collector (although, and this confirms it, memory reclamation is not guaranteed). It’s time to read up on the garbage collector and COM Interop.

I used Visual Studio 2003 and Office 2003 to test this.

Technorati Tags: , , ,

.net

Three * Virtual PC WinXP SP2 images created…

That’s me just finished creating a clean VirtualPC 2004 image with Windows XP SP2 installed.

I made a few copies, mostly all for use with products that are still in beta.

I’m only allowed to tell you about one product that I’ll be looking at and that’s Microsoft Visual Studio 2005.

Expect to see more posts as I spend more time living inside the Visual Studio IDE.

Incidentally, those generous folks over at Scottish Developers have some Visual Studio 2005 beta 2 boxed DVDs to give away, all you need do is attend a meeting or day conference (or if you’re lucky, speak to Craig nicely and he might post one out to you! You must be a signed up member of Scottish Developers though!)

Delphi, General

The Best of Delphi 2005

the best of Delphi 2005
On the 29th of November 2004 I will be speaking at The Best of Delphi 2005: an event organised by The Developers’ Group.

The event takes place here: 1 Whitehall Place, London, SW1A 2EJ and starts at 0900 – be there!

The full agenda can be found here.

I’ll be speaking about two subjects: refactoring and XML Web Services.

Refactoring
I don’t know about you, but I’m a lazy coder: I like my IDE to help me as much as possible. I used to be happy with simple stuff like indenting or “outdenting” blocks of code. Then along came code completion, heaven! Naturally I crave for more, more productivity gains, more guarantees that the code I write is syntactically correct and it is consistent.

The refactoring support in Delphi 2005 provides such guarantees: no longer do you have to rely on cut’n’paste to move chunks of code around (many a customer-facing error has been made with “cut’n’paste”!).

Use Refactoring To Move From Win32 Delphi to Delphi 2005
Moving your application from one version of Delphi to another is never quite as easy as it looks. Even more so if it’s from Win32 Delphi to Delphi for .NET!

Consider a legacy Delphi 5 application that was written around the time Delphi 5 was released. Like all code that was written “a while ago” (a couple of weeks ago in my case!), you probably look at some old code and think: “did I really write that?” and/or “I haven’t a clue how that piece of code actually works”. If those quotations ring true for you, Delphi 2005’s refactoring (and unit testing) is something you should be very interested in: refactor what you don’t understand.

Delphi 2005’s refactorings will let you re-write (alter the design of) your old code whilst preserving the functionality. Similarly, if you don’t understand how a piece of code works, Delphi 2005’s unit testing will let you write tests to “surface” an understanding.

If your application doesn’t use any third party components, then moving from say Delphi 5 to 6 or 5 to 7 is probably the simple matter of a recompile, perhaps with one or two minor code changes.

However, if your application uses third party components, your move to a new version of Delphi typically will involve an upgrading those very same components! And this is where it can get a little hairy. My experience has shown that moving a moderate-sized application from Delphi 5 to Delphi 7, whilst taking into account a raft of third party component upgrades, sparks off the need to re-test and often re-write large parts of the application.

Similarly, moving from Win32 Delphi to Delphi 8 or Delphi 2005 also necessitates that your application is retested after the move.

It is for reasons like these that Borland have incorporated two features into Delphi 2005: refactoring support and unit testing via NUnit. Refactoring brings with it the productivity gains we are all looking for and NUnit provides us with a means of ensuring that the refactoring hasn’t broken anything. Refactoring and unit testing are made for each other: I will cover refactoring during my session and Dr.Bob will cover unit testing in his.

Attend this session if you want to learn how to be more productive within the Delphi IDE (Win32 or .NET), how to be more responsive to your customer’s [changing] needs and how to bring your application to market faster thus encouraging an early return on investment and realising profit sooner rather than later.

XML and Web Services
Between Delphi 6 and Delphi 2005, the bottom line functionality of Delphi’s support for protocols like the Simple Object Access Protocol (SOAP) and web services hasn’t really changed very much. Granted, there have been bug fixes and upgrades to support newer versions of World Wide Web Consortium (W3C) standards, but if you look at the applications that can be created using Delphi, not much has changed.

So why spend 45 minutes talking about it?

Well, there are plenty of good reasons, least of all:

1. Delphi 2005 could be the version you have been waiting for: a lot of folks follow “odd numbers”, Delphi 3, 5, 7…Delphi 2005 is the next logical version. If you plan to adopt Delphi 2005, and you are coming from Delphi 5, then it is possible that your Delphi 2005 application architecture will need to involve web services.

2. Delphi 2005 could be the version that you plan to “migrate to .NET” with. You’ll need an understanding of what’s in .NET that can help you: this session will provide you with an understanding of how to integrate your application(s) using .NET’s XML support and will show you how to interact with other applications running elsewhere on the Internet.

Building applications that rely on web services to serve up their functionality might sound odd. However, think about how your existing applications are architected: you probably use “layers” or abstractions to shield GUI functionality from database access functionality, for example.

Building an application using web services instantly gives you a layer of abstraction: you can implement functionality once, and then use it from a GUI client application, and web client application or even a mobile device – anything platform that is capable of consuming a web service could potentially become a user of your application.

This suggests that your application could be used in more remote locations….increasing the return on investment and bringing your application into profit much sooner.

Development

Hire Developers, Not Programmers

Eric Sink has written another fine article. His first article, Make More Mistakes was fantastic – if you’ve not read it, I can strongly recommend it.

In his article about the Hazards of Hiring, Eric must have been sat at the back of one of my presentations: he describes “programmers” and “developers” in exactly the same way I do! Indeed Eric has blogged about it here. Another fine piece of writing.

When necessary, however, I do state that some tasks bring the developer down to the same level as the programmer. For example, when discussing Test-Driven Development (TDD), I believe it is the person at the coal-face who should be writing the programmer tests. Whether a developer writes them, or a programmer writes them, in my opinion is neither here nor there.

However, as for Eric’s thoughts? I agree: I was a programmer in my youth, I just churned out code.

Back then, despite my title (Library Programmer), I became a developer…because the distinction Eric and I agree on wasn’t written down back then. The team I worked with also were developers: we took an open-minded approach to challenges, in many cases turning what might have sounded almost impossible into reality.

After that, I took a position that allowed us to customise our job title to suit what we were doing at the time: enterprise development. We kept a focus on the bleeding edge – everything we did involved XML, it was so cool back then. Nowadays of course, XML has its place, but we don’t have an “XML everywhere” scenario anymore.

Since then, I’ve still kept the word ‘development’ in my title: because I believe that one shouldn’t pick a single track and follow it. It’s important to be able to lend a hand to many tasks without selling yourself as a Jack of all trades, that’s totally different from being a Developer.

Nowadays, I’m a Certified ScrumMaster, with a strong bias towards all things Agile. I can see how Agile could have helped me/us on earlier projects. Equally, somewhat prophetically, can see that Agile will bring my current project in on time and within budget. So much, so I’ve signed up to SellingAgile, Clarke‘s Yahoo group aimed at individuals and developers who need to understand how traditional approaches can be improved by adopting Agile approaches.

Lending a hand to many tasks facilitates getting the job in hand completed through team-work, drive and focus. Developers can do this, they have the mind-set – hire developers, not programmers: good advice, I’ll follow it when I set up my own shop.

Development, TDD

How big are your steps?

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience.

The slides are free to download here (1134k). Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

Read more about the session here.

Tied in with this debate was a lengthy discussion about the concept of “small steps”.

Early on in my session I took lots of really small steps, panicking the audience slightly as they wondered how long it would take me to get from 1 to 2000 in Roman numerals (I was applying TDD to a Roman numeral conversion class).

TDD promotes the notion of taking plenty of small steps, gradually taking slightly larger steps as your confidence increases. However, the instant you step over your mark and take a step that’s too large, you should revert to taking smaller steps until to regain your confidence.

The size of TDD steps is important and it’s one that you have to be happy with yourself: a “small step” that works for you might be a large step to somebody else. It’s about finding a happy medium – go out and try TDD for yourself, make the mistakes that I did, take large steps, try to do too much in a method and test. It’ll all come out in the wash and eventually as Erich Gamma said, you’ll be “test infected”

Want to learn more about TDD? These books are highly recommended:

Test-Driven Development in Microsoft .net
Test-Driven Development: a practical guide

Test-Driven Development: a practical guide: Reviewed here.

Test-Driven Development by example

Development, TDD

Doing “the simplest thing”

2 Comments

I re-ran my An Introduction to Test-Driven Development session yesterday…to an exceptionally interactive and responsive audience. The slides are free to download here (1134k).

I was using DUnit with Delphi 7. I re-iterated the fact that eXtreme Programming and TDD extol the virtues of “doing the simplest thing that could possibly work”.

About half way through my session (which could easily have run on to 2 hours had dinner not got in the way!) a well-respected friend, Adrian, raised his hand and said: “Building a class isn’t the simplest thing!”

I had built a class that converts integers into Roman numerals. The first step was to add a method, toRoman, that took an integer and returned nothing. The second step was to have it return ‘I’ when ‘1’ was passed in as a parameter. Feel free to download the Delphi 5-7 code, the Delphi 8 code or the Visual Basic.net code.

Of course, he was right, building a class that has one method returning the letter ‘I’ is overkill. It’s not the simplest thing. Everybody knows that the simplest thing would have been a simple function with no class wrapper and no hint of object-orientation.

I realised that what I had done was the simplest thing the could possibly work in this xUnit testing framework. It wasn’t the simplest thing that might get the job done.

Similarly, in an earlier re-run of the same session, Andy, pointed out that my idea of the simplest thing perhaps wasn’t his. And herein lies one of TDD’s ironic facets: whilst TDD provides us with a great understanding of “how” a piece of code should be invoked, thus increasing the chance that somebody other than the original developer/programmer will be able to understand it, TDD can be an emotive process.

TDD will help you as far as your “under the bus count” goes, it will give you the most accurate form of documentation that you’ll ever have for your code base, but it won’t help you ring fence or blinker your programmers in to writing code the in the same way. But, since that’s not something any of us should relish, Borg-like programmers churning out the identical code for the same problem, it shouldn’t put you off TDD.

I’ve just googled under the bus count only to realise that it’s not defined anywhere.

I’m using the phrase to mean:

    the number of people on a project who need to be run over by a bus, that will then make the project fail or incur a severe cost/time delay

If you are on a project with a team of one: yourself, then the under the bus count is one. If one person, you, is run over by a bus, the project fails, or meets almost insurmountable cost/delays. Of course, if it’s just you on the project team, you probably don’t need to worry about who’s going to be picking up the project after you’re gone!

Ideally, you should try to drive your under the bus count upwards, away from one. There should be no single point of failure, no empire-builders.

Go practice TDD, trust me, it works. It heralds a new confidence that will allow you to improve (refactor) huge chunks of your code base that you’d probably never want to touch citing “if it a’int broke don’t touch/fix it”…when you know perfectly well that the internal design is like a house of cards and won’t survive the next bout of customer change requests. It improves the quality of your life…there, what else goes this far?

Want to learn more about TDD? These books are highly recommended:

Test-Driven Development in Microsoft .net
Test-Driven Development: a practical guide

Test-Driven Development: a practical guide: Reviewed here.

Test-Driven Development by example

Book Reviews, TDD

Test-Driven Development: a practical guide – book review

Test-driven development (TDD) has become very popular in recent months. Until now there was only one textbook on the subject: Kent Beck’s. “test-driven development: A Practical Guide” by David Astels, was published in July 2003 and complements Beck’s original TDD work. This book is part of The COAD Series, named after Peter Coad, Borland’s Senior Vice President and Chief Strategist. The book itself is a little over 550 pages long and offers up-to-the-minute advice on how TDD can change your development and testing philosophy.

Read the review here.

Delphi

Developer day in Marlow

I have just returned from Marlow, a quaint little village on the river Thames to the west of London. Like Edinburgh, I can’t afford to buy a property there.

Marlow isn’t a developer Mecca, so why was I there?

Well, Delphi’s chief architect and one of Borland’s Chief Scientists, Danny Thorpe came over to talk about Delphi 7 and 8. Danny gave us a great overview of the people processes behind Delphi 8’s language implementation and how he/they are trying to work out what’s best to do for Win32 Delphi: we were entertained when Danny related a story about typeless var parameters and discussions with Anders Hejlsberg. Anders asked Danny: “what are you doing going there?” to which Danny replied “we didn’t start this thing”! For non-Delphi readers, Anders designed/built Delphi; he then moved to Microsoft where he became the Lead Architect for C#. Obviously Danny and Anders still talk to each other!

Brian Long also gave us an introduction to ASP.NET using Delphi 8. Brian’s session concentrated on building a simple authenticated web-site with two pages. This was sufficient to demonstrate how ASP.NET’s “roundtripping” to the server works and how HTML pages can maintain their state (e.g. the contents of listboxes) using ASP.NET’s notion of “viewstate”: a simple hidden <input > element that stores information about the page. This raised an interesting question about security: viewstate is obscured but not secured. Brian now works for falafelsoft – these guys don’t have blogs, they have flogs. It was this idea that made me think about calling my blog a slog. I still might.

Bryan Crotaz arrived traditionally late, unflustered despite an installation problem at the BBC (how difficult are TVs getting to install? I dunno). Bryan talked about ModelMaker and Bold in a Win32 (Delphi 7) environment. Model Driven Architecture (MDA), that was the focus of the session. As usual Bryan made it look very easy, however I suspect my mileage will vary when I sit down to go through it.

Borland’s Jason Vokes (blogless at the time of writing), gave us a whistle-stop tour of “what’s in the box” for the various Delphi 8 editions. This wasn’t really what I was expecting – having been privy to some of the “ideas” bouncing around the Developers Group, I took this to mean “provide more than just an explanation of what was on the CDs” (sorry Jason, honesty gets the better of me!) I was expecting/hoping for an overview of each product and the chance to see the product in action. As an aside, the June issue of The Delphi Magazine will be publishing my review of ProDelphi, which you’ll find on the Companion CD!

Overall it was a good day, good food and good people…if I had a digital camera I’d show you the free mug we all got. But, I don’t, so I can’t!

It was particularly good to catch up with the Team DCon, folks I expect to see once a year. However because there is no DCon 2004, :-(, I’ll have to make do with this trip, so far.

Sadly, Team DCon is one member short: Jon Jenkinson, 1963-2004.

Technorati Tags: , , , , , , , , , , , , ,