Quality Coding
Shares

How to Use SwiftLint for Clean, Idiomatic Swift

Shares

We get feedback from the compiler. We get feedback from Test Driven Development. But what sources of feedback lie in between?

This is where linters come in. A linter goes beyond “Does the code compile?” A linter answers questions like, “Is the code idiomatic? Is it stylistically clean? Are there any red flags?”

Continue reading

What Can We Learn from an Incorrect TDD Diagram?

Shares

A paper published in 2013 about Test Driven Development included the following diagram. Unfortunately, it gets some things wrong:

incorrect TDD diagram

Continue reading

Generate Test Scaffolding & Stay Focused

Quickly generate code for either Swift or Objective-C. Code snippets provided for both Xcode and AppCode.

Where Will Jon Be in Fall 2017?

Shares

Do you enjoy conferences and workshops? Here’s my conference schedule for this fall:

October 7–8: Intro to TDD (non iOS) in San Jose

Last year, I attended Silicon Valley Code Camp for the first time. This year, I’ll be teaching a session: Intro to Test Driven Development.

This won’t be specific to iOS development. Instead, it’ll be platform agnostic, for anyone with a little programming experience.

This year, it’ll be hosted at the PayPal campus in San Jose, California. My session will be Saturday morning at 9:45.  You can’t beat the price, which will be little more than a nominal lunch fee.

Send any programmers you know in the area. Also managers! They’ll get a taste of TDD from someone who’s been practicing it since 2001.

Register for SVCC

October 25–26: TDD Workshop in Seattle

My one-day TDD Workshop for iOS Developers has been well-received in Verona, San Jose, Chicago, and Indianapolis. This time, it’s coming to Seattle as part of Swift by Northwest.

The last time I taught the workshop (for a company, not a conference), I kept saying, “Wow, there’s so much we can cover. This could easily be a two-day workshop.” So guess what? This time, you can spend two solid days with me, learning Test Driven Development for iOS!

Register for Workshop

October 27–28: Swift by Northwest

The intimate traveling conference CocoaConf has stopped traveling. It’s roosted in Seattle, and taken on a new name. I’m honored to be included in the launch of Swift by Northwest!

My session will be on the SOLID Design Principles. But I want to try something a little different this time:

  • No slides. Live scribbling instead.
  • Not a “presentation,” but a seminar. There will be discussion.

I think it’ll be a lot of fun. From our shared experiences, we’ll all become better software designers.

Register for Swift by NW

Will you be at any of these events? Let me know by leaving a note below!

Single Responsibility Principle: Is It a Fundamental Mistake?

Shares

The “Single Responsibility Principle” (SRP) sounds so noble. But I’m afraid it’s misunderstood and misapplied. Ask your teammates: “What is the Single Responsibility Principle?” Go ahead, ask them. Then ask if the SRP is a good thing or a bad thing. I’d bet many of them will say something like this: “In principle, it’s a good idea. But in practice, it’s overkill.”

Single Responsibility Principle poster: monster Swiss Army knife

SOLID Motivational Posters by Derick Bailey, used under CC BY-SA 3.0 US

On Twitter, Chris Eidhof pointed to an example of taking the Single Responsibility Principle too far. Specifically, Chris was unhappy with the argument that Singletons violate the SRP because, besides their main responsibility, they also manage their own life cycle:

This led to a lively discussion. Many reacted against “over-architecture.” No doubt they experienced fragmented code that grew from over-zealous attempts at SRP.

I think that SRP isn’t just over-applied. It’s fundamentally misunderstood, even misquoted. The repeated misquotes perpetuate that misunderstanding.

Let’s see if we can clear things up, and point to a better way.

Continue reading

Automatically Generate Swift tearDown with This AppCode Plugin

Shares

Those of you who are regular visitors to qualitycoding.org may have already read Jon’s article outlining the life cycle of XCTestCase objects during the execution of a test suite. If you haven’t, or you want to refresh your memory, take a moment to read the original article.

Jon discusses the importance of the setUp and tearDown methods. And, more specifically, why we should be deallocating our properties in the tearDown method.

Writing a tear down method is one of those repetitive tasks. It follows a specific pattern: all properties should be set to nil. It doesn’t really require any brain power. It’s just one of those annoying tasks that you have to remember to do when writing a test.

It’s tasks like this that should be automated. And now with the Swift tear down inspection AppCode plugin, we can.

Continue reading

Please Take My 2017 Reader Survey

Shares

I want to ensure my platform does the best possible job of answering your needs and interests. And that means I need to know more about you. To do that, I’ve created my 2017 Reader Survey.

feedback

Would you please take a few minutes to fill out the survey? By doing so, you will ultimately be helping yourself. Why? Because you will be helping me create content even more interesting and relevant to you.

Your input is important to me. The survey is easy to fill out, and the results are completely anonymous. I can’t tell who said what. And you can finish in five minutes.

Yes, I’m Happy to Help. Take Me to the Survey!

Thanks in advance for your help.

Refactoring Demo: Is It More than Just Changing Stuff?

Shares

Refactoring. It’s a word I hear quite a bit. Usually, in the context of conversations with management, it means, “Rewriting that thing. Hopefully without introducing bugs.” Often, among developers, it means, “One of the options in the Refactoring menu in my IDE.”

Continue reading

Revealing Hidden Objects: Can DDD Improve Your Code?

Shares

Code that’s easier to understand, maintain, and extend — that’s the promise of Object-Oriented Programming. But the reality for many iOS developers is that our objects are bloated. They know too much, and do too much. What if our code has hidden objects, waiting to be found?

Each hidden object could provide a new abstraction, a new tool. They could make the code more manageable. Is there a way to discover these hidden objects? Domain Driven Design (DDD) provides a way.

Continue reading

Swift Mock Objects: How to Avoid Fragile Tests

Shares

CLICK HERE to download the Swift Mock Objects sample code.

I’ve written about my experience of going to try! Swift Tokyo 2017. Now thanks to the video and transcript provided by Realm, I can also share the talk I gave: “Making Mock Objects More Useful”.

Speaking at try! Swift Tokyo on Swift Mock Objects

I start by showing the basics of how to make a Swift mock object by hand. But this easily leads to fragile tests because the assertions are overspecified. We need ways to make tests more malleable, with mocks that are more flexible.

Continue reading

How to Safely Parse JSON into Swift Immutable Models, All with TDD

How can we unit test JSON parsing, handling every possible error? Can we generate immutable models? And for Swift, how can we keep our Response Models free of optionals?

Of course, there areb many JSON parsing libraries out there. Plug one in, define all fields as non-optional, and you’re good to go! …Until your app crashes, because something was different in the actual JSON data.

Unlikely? “The backend team would never do that to us”? I’ve had a released app crash because the backend folks changed one field from a string to an integer. I’ve seen app development and QA forced to pause because a commit assumed all fields were non-optional. (It crashed on the missing field, because Swift.)

So let’s look at a pattern that will help us

  • Handle required types
  • Avoid optionals
  • Deliver immutable models

Even if you never plan to do your own parsing, we’ll learn things along the way about design and testing.

Continue reading

1 2 3 11