small medium large xlarge

Back to: All Forums  PragPub
Generic-user-small
04 Oct 2012, 11:45
Sergey Moshnikov (4 posts)

The article by Jonathan Rasmusson “It’s Not About the Unit Tests” from the latest PragProg Magazine left me really puzzled.

I think I understood the message the author wanted to deliver: the quality is not about specific practices, but about the attitude and applying them mindfully.

Then, the author states that iOS developers really care about quality. I totally agree with that, having seen so many amazing iOS applications. Yet from his article, I’ve got the impression that iOS developers care mostly about external quality of the product: art, element layout, affordances, etc.

But, does it all say anything about internal quality? What about product maintainablity, extensibility, and all other -ilities which are not visible from the outside? That’s actually where we see the value of TDD.

How do iOS developers approach these problems, if they don’t use TDD?

Jr-profile-smaller_pragsmall
04 Oct 2012, 15:21
Jonathan Rasmusson (17 posts)

Hi Sergey,

Thank for asking this question. This is a conversation I have been wanting to have - so thank you for kicking it off.

Quality is a very hard term to define. It takes on so many meanings and manifestations that as soon as you start to define it, you find there are no limits and that it can be very hard to describe.

As a developer, and long standing member of the Agile community, I had a very specific narrow view of quality. Unit tests were one of them.

But when I got into iOS development, I saw a body of work and craftsmanship that I could only saw was quality, but was using non of the quality practices I had been used to applying (unit testing and TDD among them).

This really puzzled me. Was I wrong? Were these no longer applicable?

The article you read was my first attempt at highlighting these differences in views of quality, and explaining why there were there.

So in summary:

Do I believe unit testing, TDD, refactoring, and continuous integration are good practices for internal code quality? Yes.

Are they the only measures of quality? Obvious no.

Will I continue to yes them? Yes, when I can.

Will I stop producing quality work if I can not use them. No.

Cheers - Jonathan

Generic-user-small
04 Oct 2012, 16:40
Sergey Moshnikov (4 posts)

Jonathan,

thanks for your response. I’m very interested in this topic because I’m preparing to jump in the boat of iOS development soon, and I used to think I could take my usual toolkit (TDD, refactoring, incremental changes) with me. I also read about existing testing frameworks, so I thought that TDD was as usual in iOS dev world as in, say, Java.

What I want to emphasize is that I don’t regard these practices as measures of quality. Instead, I use them as tools to keep the quality of my code on an appropriate level, where “quality” is not only the absence of bugs, but also the internal design of the application, architectural decisions, code cleanliness, etc. Would I be producing the code of the same quality if I don’t write unit tests? Probably, I will. But most likely, the lack of tests will keep me from refactoring, and the design and architectural defects will start to accumulate, and the code will start to rot… I saw that several times when I was too lazy or too short-sighted to skip doing TDD. Using the analogy from your article, I can throw away my GPS navigator and get back to navigating by the stars, but what are the chances I’ll get to where I want and in time?

So, I’m curious to know from your experience, what toolkit iOS developers use to keep their code clean, maintainable and extensible? And more importantly, why they don’t use unit tests and TDD for those purposes?

Generic-user-small
04 Oct 2012, 22:07
Stefen (1 post)

Unit tests are like seat belts. I wear my seat belt all the time, because I don’t know when an accident might occur. I write unit tests all the time, because I can’t predict the future.

Based on the arguments presented. One could argue that I shouldn’t wear a seat because I never get into accidents. It’s fairly obvious that I should always wear my seat belt. Just like it is fairly obvious that unit testing is something we do for the 1% of the time when everything has gone horribly wrong.

Generic-user-small
05 Oct 2012, 10:33
Sergey Moshnikov (4 posts)

2 Stefen:

I have no doubts Jonathan understands the value of TDD. And I’m sure that he (being the author of “The Agile Samurai”) is experienced enough to notice when things go wrong with the code due to the lack of testing, or refactoring, or whatnot. That’s why I’m so extremely interested in him sharing the experience of being an iOS developer.

Relying on Jonathan’s experience and knowledge, I assume that in iOS community there are other development practices that bring the same benefits that TDD does. Or, probably, there are specifics that make TDD inefficient for iOS development. Or, there’s a “factor X” which we fail to recognize.

Jonathan, your thoughts?

Jr-profile-smaller_pragsmall
05 Oct 2012, 14:02
Jonathan Rasmusson (17 posts)

Hi Sergey,

I see two parts to your excellent question. One practical. One more based on intent and spirit.

On the practical side iOS developers use all the same techniques others user when writing software. OO, abstraction, encapsulation, modular programming, decomposition, refactoring (though the tools aren’t there), and on more advanced teams continuous integration with a smattering of TDD when possible. Some also make heavy use of acceptance testing frameworks like Frank (a Cucumber-esk inspired by Selenium).

Now, why not more unit tests? I don’t believe it’s because of a lack of will. As I try to explain in the article it is more the nature of applications that are being written themselves. They are very visual. Like the early days of unit testing the visual side of any Java, C#, and Javascript, it is just easier to fire up the browser to see if it works, then to write extensive unit tests into APIs that don’t lend themselves easily to testing.

And like Kent Beck insightfully said when he wrote the first version of JUnit: “If it isn’t easy, developers aren’t going to do it.” (paraphrased).

So what do iOS developers do when they can’t unit test? (Now we are getting into the second part of my answer).

They do whatever it takes. They care. That is there ‘toolkit’.

They ramp up their manual testing. They write automated acceptance tests. They spend hours testing, tweaking, simulating, every possible thing that can go wrong on a mobile device (lots can go wrong). They sweat and agonize over the placement of individual pixels. Almost none of which can be solved with a ‘unit test’.

I know how you feel. I would have asked the exact same question myself a year ago before I had gotten into iOS development.

All I can say to those how remain skeptical is to go and build an iOS app yourself and report back your findings.

That’s all I am doing here. I found I couldn’t work the same way I did before. And while that was initially frustrating, I also began to see how limited my view of quality was, and how much bigger it was than my narrow set of ‘practices’.

That doesn’t mean my practices were bad. I feel they are very good. It just meant I had to adapt how they were applied. And maybe pick up some new ones along the way.

I think the iOS community could learn a lot from practices pioneered in the Agile community around writing quality code.

I also think the iOS community has a lot to teach the Agile developer community about quality. Especially beyond the code.

Cheers - Jonathan

Generic-user-small
06 Oct 2012, 09:30
paul callaghan (14 posts)

hi

I enjoyed the article too, great addition to the wider debate.

There’s some interesting connections with my haskell/fp articles as well, eg use of types, declarative style of coding, …

Paul

Generic-user-small
07 Oct 2012, 07:10
Sergey Moshnikov (4 posts)

Jonathan,

I had to read your posts a couple of times, still having a funny feeling of a blind man trying to understand the the concept of color :) But I hope I finally understood the message. I’ll try to say it in my own words, and you correct me if I’m wrong.

So you say that in iOS community the concept of quality is wider than in, say, enterprise world. That iOS developers care a lot about such subtleties like visual part, user experience and enjoyment, application speed and performance. And that they don’t stop working on a feature when the code is in place. They play with the application, tweak and polish it to bring the best user experience they can. That’s what you mean when you say “they care”.

Am I getting the message right?

Sergey.

Jr-profile-smaller_pragsmall
08 Oct 2012, 02:49
Jonathan Rasmusson (17 posts)

You got it.

A more abstract way of summarizing it would be that ‘caring’ trumps any individual practice. And that just because others don’t work like you, you shouldn’t be quick to judge until you’ve walked a mile in their shoes.

Jonathan

Generic-user-small
14 Oct 2012, 22:29
Maksim Lin (1 post)

Thanks for a very interesting piece Jonathan.

Tim Bray has also written on this topic but points to the difficulty of unit testing mobile apps vs webapps the the breadth of available APIs on mobile vs serverside development.

But what worries me is the lack of objective measures for quality. Certainly there are plenty of subjective one that you quote that ios developers worry about UX, excellance in graphical, etc. Yet how do you know how many times your app encounters an error out in the field or how often a user gets trapped in a invalid state? Server side you can collect huge amount of metrics regarding the use and rpoper functioning (or lack of) a webapp. Are you using one of the metrics collection webservices for your iOS app?

And I also agree with you about the lack of maintaince currently required for mobile apps right now. Unlike webapps that could have production deployments lifespans of 5 years or more, I doubt there are many apps that have been through even 1 major enchancement cycle or need to be enhanced/developed by developers other than the original developer of small team.

You must be logged in to comment