Frank Carver's musings about software and life
This looks interesting. The role of testing (at least, testing beyond unit-level regression testing and TDD) is the subject of much discussion in software development at the moment. Maybe I should actually attend this talk at Skills Matter in London on 18 September.
When I first saw this it looked great: a ruby REST wrapper which supports a lot of useful test and integration possibilities. However, the deeper I looked, the more disappointed I became. I’m now saddened to believe that this is based on yet another misunderstanding of what REST is.
As far as I can tell, the ActiveResource concept, on which this approach is based, is merely an attempt to impose a constrained CRUD data-model over HTTP. There is no concept of content negotiation – all data is XML according to pre-assumed schemas. There is no support for automatic discovery and use of hrefs between resources. There is even the suggestion that it’s a good idea to casually extend the HTTP protocol with extra custom methods.
All of these are typical problems found in projects which use the name REST without the key bits which make it really work. The end result is just another fragile, application-specific RPC protocol. Sigh.
nutrun » Blog Archive » Testing web services with ActiveResource
I just found this link in my drafts. Still worth looking at if you are interested in a holistic view of agile development.
I have recently discovered a new blog to follow: “notes from a tool user”. The author, Mark Levison has plenty of opinions on agile software development.
Standout recent articles include:
In almost all areas of software development, and especially in test-Driven Development (TDD), testing is vital. In many ways, automated testing by developers is even more valuable. However, as Jay Fields points out, attitudes to, and practices of, testing vary greatly.
I’m sure we have all encountered the situation where supposedly-helpful automated user-interface tests become a weight which drags down the agility of a project. The usual upshot of this is that either the project stops being “agile” or the offending tests are “temporarily” bypassed, and never run again.
Manish Kumar has written an article about this: Agile Testing ,Lean principles: Why Testing is perceived as least agile: What needs to change
Interestingly, in his choice of solutions he does not include my personal favourite – writing/changing the tests before implementation, and letting the new tests be the specification for the work to be done. This way the effort of changing the tests is in itself valuable, particularly as it might lead to a reduction in excess documentation of specifications before work can start.
Somewhat of a rant against traditional, and often big budget, record/replay acceptance testing tools.