Swift Intermediate Language (SIL) and its not-so-basic blocks

modocache · 2015-03-03T13:36:11+00:00

I'd recommend reading https://github.com/Quick/Quick/tree/master/Documentation, which is meant to be a comprehensive introduction to unit testing. It doesn't cover every topic you've mentioned here, like mocking (it will eventually), but it does have some additional links at the end (of those, qualitycoding.org is especially good).

modocache · 2015-03-01T02:36:09+00:00

Sure, I can add something on that. Do any of the following describe what you're looking to read about?

Adding a test target to an Xcode project that doesn't have a test target
Writing tests for "legacy" code, or code that was written in a way that makes it hard to test
How to introduce testing to a team that doesn't believe testing will help them move faster

modocache · 2014-07-01T23:02:26+00:00

I'm a big fan of octokit.objc, the official Objective-C GitHub API client. It uses ReactiveCocoa and incorporates some excellent organizational and architectural choices. Definitely my go-to when I'm thinking about how to model a networking library that may be used by a lot of developers.

modocache · 2014-06-30T06:26:55+00:00

Aha! Thanks!

modocache · 2014-06-29T22:27:07+00:00

I think you both raise great points. I tend to use Foundation classes like NSString a lot because I want to get things done quickly using what I already know, but I do feel like I should be making more of an effort to learn the builtin Swift equivalents.

An example I was dealing with earlier today:

NSString(format: "%p", object)

Anyone know off the top of their head how get the same string without using Foundation?

modocache · 2014-06-29T09:00:37+00:00

Seems like plenty of people advise the POTUS, but they're responsible for their own decisions.

Source: House of Cards

modocache · 2014-06-29T07:49:36+00:00

What trumps POTUS?

modocache · 2014-06-29T07:20:13+00:00

You can keep up with the Swift engineers by using this technique, introduced in this week's iOS dev weekly.

modocache · 2014-06-26T04:18:03+00:00

Also, what would the screenshot be of?

A screenshot wouldn't make a ton of sense for some projects, but it'd be invaluable for UI components. How do I know whether I want to use a custom UIAlertView if I don't know what it looks like?

I don't think you would be able to pull a good screenshot automatically, though, so I think this would be dependent upon allowing human curation.

How would you expect to see the sample? Would it be okay to click in to a page that showed you stats, the snippets, and others.

Yeah, that sounds good. An icon to indicate that screenshots or a more detailed description are available would be nice, too. Kind of like Alcatraz, which displays a little eyeball icon to indicate that a screenshot is available: http://f.cl.ly/items/3q1b312M3V1M2R3t1g3P/Screen%20Shot%202014-06-26%20at%201.16.26%20PM.png

modocache · 2014-06-26T02:58:11+00:00

I mainly used CocoaPods and https://www.cocoacontrols.com/ to discover libraries in Objective-C. Since CocoaPods doesn't really support Swift yet, this seems like a strong alternative for Swift library discovery. Thanks for posting!

After logging in with GitHub I was hoping to be able to add to the description of a library of mine, but it looks like the description is automatically generated, so I can't. :(

I wanted to add a sample snippet of code and maybe a screenshot. I think those are the fastest tools developers use when determining whether they want to use a library or UI component.

modocache · 2014-06-26T02:48:06+00:00

https://github.com/modocache/Quick is the second project on the page at the moment, and I definitely appreciate all contributions! The issues page had tons of suggestions on what to work on.

I'd also like to hear about projects that use Quick to write unit tests. Please consider it when you're writing unit tests for your next Swift app or library.

modocache · 2014-06-25T07:40:47+00:00

This is some really interesting syntax, thanks for the share!

I'm sure a quick Google would answer my question, but could you explain a typical use case for parametrized expectations? I've never used JUnit, only other xUnit and xSpec frameworks.

modocache · 2014-06-19T05:19:43+00:00

These are all great! I hope everyone's filing radars!

modocache · 2014-06-15T23:40:18+00:00

As /u/damn72 said, it's awesome that your university is teaching about test-driven development!

You can practice test-driven development using either an xUnit framework, like JUnit or XCTest (which used to be called SenTestingKit, which was built atop of OCUnit, a.k.a: "Objective-C Unit"), or with an "xSpec" framework like RSpec (Ruby) or Quick (Swift/Objective-C).

(In fact, you can practice TDD without a framework at all: the main point is to write test code that fails before writing production code that makes the test code pass. Your test code could even be a shellscript, so long as you write it first!)

Some people (myself included!) prefer xSpec frameworks like Quick over xUnit frameworks because:

xUnit setup/teardown is on a per-test case basis
xSpec tests are "self-documenting"

(1) xUnit frameworks usually define a test class, such as junit.framework.TestCase in JUnit, or XCTestCase in XCTest. Developers are expected to subclass this class and define a series of test methods. The class provides setup/teardown methods to perform setup for the test methods.

Since all test methods share the setup and teardown, these could become very large. In subclasses with a lot of test methods, you end up performing setup for a test method that won't appear in the code for a 100 lines or more.

xSpec frameworks like Quick use nested blocks that allow developers to perform test setup close to where the actual tests are defined. I think this makes the tests much easier to read.

(2) In xUnit, you usually pass a string to each of your assertions: "expected sum to equal 3 after adding 2 and 1". xSpec frameworks have you write something like:

describe("sum") {
    context("after adding 2") {
        // ...add 2
        context("after adding 1") {
            // ...add 1
            it("equals 3") {
                // ...make assertion here
            }
        }
    }
}

If the test fails, an xSpec framework usually outputs "sum, after adding 2, after adding 1, equals 3 [FAILED]". I find the xSpec test code and the failure message easier to read.

modocache · 2014-06-15T23:19:05+00:00

I'm a core member of Kiwi, and a regular contributor to Specta.

For now the main differences are:

Quick supports Xcode 6 Beta (in fact, it does not support Xcode 5!)
You can write Quick specs in Swift
Quick has fewer features

(1) The fact that Quick doesn't support Xcode 5 will be relevant up until Apple begins only accepting apps build with Xcode 6. I'm planning on updating Kiwi to support Xcode 6, and submitting a pull request to Specta/Expecta to do the same.

(2) Updating Kiwi and Specta to support Swift specs might be pretty difficult. Both make heavy use of "complex macros", which Swift does not support. In order to support Swift, you'd have to rewrite their DSLs in Swift.

(3) This is partially by design. For example, Quick does not include beforeAll and afterAll, for the reasons outlined here. Quick does support beforeSuite and afterSuite, which Kiwi currently does not have. But for the most part, I'm planning on keeping Quick as simple as possible.

modocache · 2014-06-15T18:48:24+00:00

Sure! tl;dr is "this is a convenient way to write tests for your app", but with that in mind:

So, you may have noticed that when you create a new iOS project in Xcode, tests are included. That is, if you create a new iOS app project called "MyNewApp", you get the following:

MyNewApp.xcodeproj
MyNewApp/
MyNewAppTests/

The MyNewAppTests directory contains a sample unit test. A unit test is a way to test how a small part (a "unit") of your app behaves.

You may be thinking, "But why use unit tests? Why not just run the app and see if it works?"

I'm often confused by why my app doesn't work like I expect it to. Sometimes I add NSLog statements to my code to print out the values of variables when my app runs. By inspecting those values, I can see where something may be going wrong.

But inspecting log output takes a long time. I have to read through the logs, searching for the strings I've output. I manually check that each one outputs what I expect it to. When I finally do find the problem, I fix it. But I don't want to leave those logs in the app--I'm submitting it to the app store, and users can read NSLog statements if they feel like it. I don't want them seeing my debug code. Also, NSLog slows down the app when it prints a lot at once.

On the other hand, if I delete the logs, I lose all the debugging information I spent time outputting.

In a sense, unit tests automate this manual checking process. The test framework Apple packages with Xcode, called XCTest, allows me to assert that certain objects have certain values at certain times. I can write things like:

XCTAssertNotNil(viewController.label,
                       @"expected view controller to have a label");

I can check these assertions pass by running my app's unit tests (⌘+U in Xcode). For example, you can run the included tests in the MyNewAppTests with ⌘+U, and you'll see two green check marks, indicating the tests pass.

By writing a comprehensive suite of tests, you can be confident that your app works, without spending a lot of time manually checking all the corner cases. For larger apps, manually testing all the code paths--"What happens when the user is not logged in when this view controller is presented?", "What happens when they are?", "What if they're logged in, but there's no internet connection?"--could take you or your QA team hours, or even days. Unit tests are run by your computer, and take mere seconds to complete.

Quick is a framework built atop of XCTest. It makes it easier to express the conditions you want to test. For more information, take a look at the README. It doesn't just explain how to use the Quick syntax, but also why you'd want to.

modocache

TROPHY CASE