27 November 2013
When you’re writing software, how can you know if some test code is a “unit test”?
The “test” part of the term is obvious, so let’s look at “unit”. What is the smallest unit of software? Perhaps a single line of code? Well, if you do want to run a single line of code, you’ll have to have some way of referring to it, like perhaps a name, and at that point what you have is a function or method.
So if a method is the smallest unit of software, then I define a unit test as a test where only a single method of production code is run.
Now it’s easy, just look at your tests, and if there’s only one production method being called, it’s a unit test. If there is more production code, then it’s some kind of integration test.
But why does this even matter? Well, I find it’s hard to go wrong with unit tests, because they are so focussed, and they are not likely to make the codebase harder to change later, because you’ll only have to change a few unit tests if you change a method, and it won’t affect any other code. Integration tests, on the other hand, are more complex, and you have to be careful that you’re creating worthwhile integration tests that add value rather than just make the codebase harder to change. It’s easy to accidentally couple different parts of the code together via these tests, and make things worse rather than better.
This is what I’ve found with my work anyway, let me know if you disagree.
24 November 2013
Frank Chimero has managed to brilliantly articulate a number of key realisations about the age of software. The message is about the medium, and here the medium makes up part of the message, so be sure to watch the short videos.
20 November 2013
Some great little video snippets of our planet in this short piece.
13 November 2013
I was thinking last night about how the software industry compares to other industries. In construction there are government building inspectors and safety standards, and restaurants have health and safety standards and inspectors - what if there were software code inspectors? Random audits of our test suite and production code?
How would that change the way we write our code? Or estimate the time required? How we define what needs doing, when it’s done and how we charge for the work?
And then today I read this article on healthcare.gov:
“If I were in government right now, I would be leery of starting another big software project. I’d also know that big software projects are going to be necessary as our civilization gets more and more complex. So, if I were in government right now, I’d be thinking about laws to regulate the Software Industry.”
Years ago I wondered when and how software would start to be regulated (around the time that people started being prosecuted for accessing a computer system without permission), but then in a “follow the money” strain of thinking I thought perhaps it would be insurance premiums that finally enforced some level of quality in software systems. That doesn’t seem to have happened.
Making software is a fairly new thing historically, and it’s difficult, but surely at some point society will stop only complaining about poor quality software, and instead demand better quality? In any case, I’m aiming to make high quality software now, so that I’ll be comfortable when the inspections begin.
Update 15th November 2013: It does seem that somehow whenever software is in some way regulated or certified, that it actually has a negative impact on the quality. Perhaps it has to do with certification making the software less soft, and quality software needing to improve and adapt over time.
22 October 2013
In her statement to the Legislative Assembly on 23 June 2011, the Chief Minister indicated that the ACT Public Service would move to an information ‘disclosure as default’ position in all its operations.
I have no idea how broad this is intended to be, but on the surface this sounds like a good thing.
10 October 2013
This little story from David Smith is a great example of one of the many creative solutions that any software project needs.
As with all great thoughts, while taking a shower I came up with an interesting alternative in the meantime. I got to wondering which values get truncated and which do not. It turned out that not all values greater than 10k get shortened, any number that happens to include two 1 digits is shown in full. So that led me to the workaround solution that will be shipping in version 1.1.1.
Because this is a creative solution that came while taking a shower, it also demonstrates why great software takes time: you can’t place these solutions on a schedule before they happen.
03 October 2013
Playing with maps for fun and education.
10 September 2013
I really like the approach this site takes towards planning and keeping a budget, and I think the approach works with all kinds of planning, because a big part is realising that plans change as time goes on, and you have to constantly revisit the plan. Without that, plans are just a fantasy you throw away as soon as you start working on what you originally planned.
05 August 2013
If you have ever supported In-House Enterprise iOS apps, you’ll know that every so often the certificate expires and you need to re-sign the app with a new provisioning profile.
This is something a lot of people who make iOS apps have to do, so of course when the need arose for me, I went looking for solutions that other people had already found.
But while the first script I tried looked like it worked, it failed to change the embedded provisioning profile. And then when I tried another set of manual steps, the package was missing the entitlements, meaning the app couldn’t access the iOS keychain.
So, after a few hours of work, I’ve built my own ipa resigning script, which I’ve successfully used to re-sign an existing ipa, one with an expired profile.
With this script, all you need is your expired ipa and a new provisioning profile using all the same details, and it’ll build you a new ipa that will be able to access the keychain data from the existing install.
10 May 2013
Jon Reid writes in a comment:
“Either you’re coding to get a new test to pass, or you’re refactoring. But don’t do both at the same time. We’re basically walking on stilts: Lift one, or the other, but not both. By keeping one foot grounded, so to speak, we reduce the risk of falling over.”
I wrote the other day that I have previously used “CDD” - “commit driven development” or “change driven development” and I often found that I had feature or bug fix code in with refactoring code to support it. And when git came along I could use GitX very easily to separate that code in the commits. So I’m yet to change my style to be able to stop, refactor as required, and then continue with the feature code. And it seems that that is only really feasible when you’re actually coding just one test at a time, as in this kata.
I’m not there yet, but I’ll press on.