Dr David Parsons

davidparsons.ac.nz

Tag: test driven development

Uncategorized

Re-engineering coderetreats – bringing design to the fore

Oct 16, 2014 #coderetreat, #reflective practice, #software design principles, #test driven development by daveparsonsnz

For the last year or so, one of my research activities has been exploring the design and delivery of coderetreats. Our first article on this topic Coderetreats: Reflective Practice and the Game of Life was published in IEEE Software, the first piece of academic work to be published in this area. In that article we reported on how running a standard coderetreat with our students helped develop their reflective practice. In a post late last year I mentioned the Global Day of Coderetreat. We also gathered data from that event, which raised some interesting questions about how well these activities support the use of test driven development (TDD) and learning about the four principles of simple design. The coderetreat website (coderetreat.org) says that ‘Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.’ These principles are outlined elsewhere as the ‘XP Simplity Rules‘. However there was some evidence from our research that the usual approaches to coderetreats were not particularly effective at making these design rules explicitly understood. We also observed that many participants struggled to get started with their first unit test.

To try to address these issues, we re-engineered our most recent coderetreat so that it scaffolded the intended learning outcomes explicitly. For the first session we provided the first unit test, and suggested the second. This had a remarkable effect on how quickly the participants got into the TDD cycle. We also designed each session so that it directly addressed one of the four principles of simple  design, by providing various code and test components, building on the concept of the legacy coderetreats that have been run by others. In fact the last session was very much in the legacy coderetreat style, where we provided some poorly written ‘legacy code’ without tests, which the participants had to refactor by first adding unit tests.

We have yet to analyse the data we gathered in detail, but we do believe that there is a lot of scope to take the coderetreat idea forward with new ways of ensuring that the key elements of design understanding are made explicit in the outcomes.

Software Testing

Testing, Testing…

Jan 9, 2014 #Apple iOS bug, #LG television, #regression testing, #TDD, #test driven development by daveparsonsnz

I’ve recently been interested to see a couple of examples where the concepts of test driven development and regression testing were clearly not applied, or at least not applied as they should have been.

The first example was FaceTime on my old iPod Touch. Having worked perfectly happily for years, communicating with an identical device in the UK, it suddenly started failing, and for a while I was reduced to using the much flakier Skype. As you do, I stared surfing the web for answers to the problem. I soon found a growing number of people interacting on various on-line forums complaining about a similar issue. Clearly, the common denominator seemed to be a regression caused by a recent upgrade to the iOS operating system on iPod Touch 4th generation. Interestingly, the response from Apple, if the experiences of those on the forums were anything to go by, seemed to be one of total disinterest. However, a few weeks later, Apple quietly released the following fix for a problem that had affected ‘some users’ (i.e. many):

http://support.apple.com/kb/DL1701

Now I know, from painful experience, how hard it is to test for this type of fault, but Apple should have had regression tests in place for changes that might affect popular standard apps like FaceTime.

The other interesting example was this one, about LG televisions sending personal data back to the company, even when a privacy setting had been turned on:

http://doctorbeet.blogspot.co.uk/2013/11/lg-smart-tvs-logging-usb-filenames-and.html

Now you would expect, if this software had been test driven, that a test would have been written that ensured that activating the privacy setting meant that data could not be sent. Instead, data was still sent, along with an indication that the privacy setting was turned on. Either that wasn’t tested at all, or it was driven by a stupid test. The alternative interpretation, that LG wants your data whether you like it or not is, I’m sure, not the case.

These two examples are instructive because they emphasize how important it is to (a) drive your designs with unit tests and (b) avoid the entropy of your software with regression tests.

 

 

IT Education, Software Testing

Global Day of Coderetreat

Dec 18, 2013 #coderetreat, #Conways Game of Life, #pair programming, #TDD, #test driven development by daveparsonsnz

gdcr_ad_textGlobal Day of Coderetreat

Last weekend I participated in the 2013 Global Day of Coderetreat, joining the session running at the Xero offices in Wellington, New Zealand. Along with 2,000+ other software developers across 165 locations on all continents, I spent the day honing my software craftsmanship, pair programming with other developers, using test driven development (TDD), and working within a range of changing and challenging design constraints. A coderetreat is an opportunity to look at the same programming problem (typically Conway’s Game of Life) from multiple perspectives, without the pressure to create a finished product but using the opportunity to reflect on how we build software. I would recommend that all software developers, at whatever level of skill and experience, take a look at the coderetreat.org web site and keep a look out for upcoming coderetreats in their local area. If you can’t find one, why not run one yourself? All the information you need is on the web site. The only people who won’t gain anything from it are those who just want to show other people how great they (think they) are. Fortunately, these people are a tiny minority of the software development community. Most of us will embrace the opportunity to challenge themselves and learn from others, in a day of coding that is surprisingly enjoyable.