Thursday, 23 February 2012

When tests become hard

A friend contacted me for advice. He was having trouble writing a test for some code. I asked him to send me the code and the test so I could see what was going on.

I encounter this problem quite frequently, so I thought I'd post one of my responses...
Okay, here is where I think you are going wrong, and when writing tests becomes hard, it’s usually because of this.
  • It’s important to layer your applications. Web/Services/DB – at least conceptually.
  • What you have is a class that does everything. Web and Service. No-one can reuse your file processing logic without using the web, not even tests!
A nice way to code would be to:
  • Write a UNIT test that attempts to process a file. It passes in a file X and asserts that the result is Y. It won’t compile because you haven’t written the file processing code yet!
  • Now you write the service which processes the file
  • The test will compile and run now, but probably fail because you forgot something.
  • Now you can fix your service
  • And eventually the test will pass. You might think of more scenarios you want to add, so you create more tests.
Now you say, “I've got this service that can process these files, but I need to access it via web services”. So, you write another class which is the web service – but it only knows about web things, and just  calls the service so it doesn't know anything about processing files.
  • Now, you may choose to write an INTEGRATION test which really only needs to test the WebService stuff – because you’ve already tested the excel processing code
  • OR, you may choose to write a UI test which tests the deployed application
It really depends on the resources you have available, and what make sense to test.
But what you end up with is re-usable and easily testable code. Which is good right?
There's nothing new here. Extreme Programming and various design patterns/best practices cover off all of this. But the usual philosophy holds here:
If what you are doing seems too hard, its usually because you are doing the wrong thing.
This is extremely relevant when considering testing. I've seen tests become extremely convoluted because the design was wrong. Test First Programming can help the design because you'll find bad (hard to test) code early. I've got much more to say about this, but I don't have the time right now!

Friday, 3 February 2012

Solved - Trouble with the Samsung Galaxy S 1 phone

My wife has had a Samsung Galaxy S1 Android phone for over a year now and its been great. Recently though, she'd been having terrible battery performance and had noticed that after charging the phone overnight, it was only at 50% in the morning. My first thought was to buy a new battery, but then I figured I'd try updating the firmware first.

Thats when I discovered that windows couldn't recognise the device!! This was a big issue - how could I get all of her photos off the phone?

Solutions:

  1. Quite by accident, she plugged her phone into an iCoustic USB charger that we got with an iPod accessory pack - this fully charged the battery and now there are no battery issues. She'd been using my iPad USB charger previously and for some reason, this makes a difference.

  2. I realized that when syncing the phone with Kies I wasn't using the original USB cable that came with the phone. We'd been using a third party cable we'd bought after losing the original one. Since we'd found the original cable I tried that and there were no problems - Windows found the drivers, installed them and recognised the phone. Kies worked fine after that.


So, all is good now - the phone works fine, running Android 2.3 (Gingerbread).