サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
qualitycoding.org
func test_parseJSON() { let json = // Read JSON saved in external file let actual = Model.parse(json) let expected = Model( // Define each field, including each subcomponent, // to match the JSON ) XCTAssertEqual(actual, expected) } This may be a fine acceptance test. But we can do better for unit testing. Here are the things I find problematic: Large, often externalized input. I discuss this at t
First, let me point out the conference’s logo/mascot. The Swift bird has never been so adorable! Without a doubt, this is the cutest tech conference logo I’ve ever seen. Talks The conference spans 2 days, in a single-track format. Talks are limited to 20 minutes, so things keep moving along quickly. (As a speaker, it was a nice challenge to have to condense my thoughts into a 20-minute talk.) Almo
And here is sample code. Build SwiftMocks.xcworkspace and run the tests. Experiment with changing things in Waiter.swift to see how the tests report those changes. The official repository of Swift Hamcrest is here. Recommended BookDisclosure: The book link below is an affiliate link. If you buy anything, I earn a commission, at no extra cost to you. Refactoring: The Improving the Design of Existin
I sometimes talk to myself. Our classes often do. But there are a couple of places where doing so is risky in Objective-C: init and dealloc. This post is part of the Code Smells in Objective-C series. Here’s something I see a fair bit in code for Objective-C init and dealloc. I’ll give a simple example. Can you tell what’s wrong? - (id)initWithFoo:(id)foo { self = [super init]; if (self) self.some
With few exceptions, using Xcode preprocessor macros is a code smell. C++ programmers have had this beat into them: “Don’t use the preprocessor to do something the language itself provides.” Unfortunately, more than a few Objective-C programmers have yet to get that message. This post is part of the Code Smells in Objective-C series. Here’s a handy command to run from Terminal. It examines source
One of the first things I do when working on any Xcode project is set up code coverage. If the coverage shows a hole, I know that area is lacking unit tests. (Be careful, the opposite isn’t true: Just because some code has been touched by unit test execution doesn’t mean it’s actually covered. If altering the behavior of the code causes a test to fail, then you know it’s covered.) Many people use
This screencast focuses on the question I get the most: “Do you do test-driven development for view controllers?” It’s clearly a roadblock for many people. This screencast should remove that roadblock. It also answers the question, “Is it worth doing?” Outline: Three types of unit test verificationView controller unit tests: the trickTDD demoHow UIViewController TDD can actually help you code fast
Test-driven development (TDD) is a series of small steps. It can be difficult to grasp until you see those steps demonstrated. That’s why I made this screencast. It was sparked by a Stack Overflow question that said, “All the examples of unit testing I read about seem to be extremely simple and trivial.” The question asks how to write unit tests for a piece of sample code that uses NSUserDefaults.
Trying to be agile without the technical agile practices leads to frustration. Learn how to build maintainable iOS test code and production code. Then you can “respond to change,” because your code won’t fight you. Subscribe to our newsletter on Quality Coding techniques for iOS developers. You’ll receive free code snippets that will help you write unit tests more quickly. Quality Coding is about
このページを最初にブックマークしてみませんか?
『Quality Coding』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く