NEW: Start my new Ultimate Portfolio App course with a free Hacking with Swift+ trial! >>

Ultimate Portfolio - General question about when to write tests

Forums > Articles

For the Ultimate Portfolio app, it seems that we've for the most part built the app before building tests.

My question is regarding the timing of writing tests. If someone were to write an app from scratch, would the best approach (regarding order of operations) be building the models, then the UI and then start building unit tests? Or is it better to write tests shortly after writing each model / controller?

My question specifically to Paul (hoping he reads this):

Was the Ultimate Portfolio app built in the current order because you believe this is an optimal approach to build an app (solo)? Or was it ordered and timed in a way to optimize teaching?

If the course was ordered to optimize for learning, what in your opinion is the optimal order to pursue when building an app? (Assuming that you are not working on a team)


I would say that it depends on how familiar you are with SwiftUI, and if you are working solo or part of a bigger organisation (or plan to join one).

If you are working by yourself, and only just learning SwiftUI (or any other programming language for that matter) it is a lot to take in all at once. So testing, apart from using the simulator or loading the app on to your own device, is usually left towards the end when you are more comfortable with the language and programming environment.

When you are more familiar with SwiftUI, I would start off by outlining the requirements, and determining the tests (a 'test plan' so to speak) to make sure that you cover all the critical or program sensitive areas, such as proper use of CoreData, etc. The higher level of understanding of the language will mean that you are able to specify, design, implement, test and document code from the requirements and do this for meaningful chunks of the app. This, if you are familiar with the term, is the Agile approach to programming (actually to product and system design more generally), and that after each module or part module is implemented, the resulting product is always useable, even if not all the features are completed yet.

I think that simply put, when you are more confident in using SwiftUI you will probably get in to a cycle of write down your key features, code a bit, test a bit, document it, code a bit, test a bit, document it, . . .

At least this is my thought.


I agree with @Greenamberred, the sequence in the tutorials is probably to make it easier to learn one chunk at a time.

In my own career I have found it really useful to write tests in parallel with writing application code, especially when I'm working on a feature that I've never implemented before. I find the test really helps me to make sure that my function (object, subsystem, component, whatever) does what it's supposed to do so that I can plug it in and start using it with confidence.

For example, I'm currently writing an application to be a Twitter client, and I'm trying to use a Redux-like structure in the app. Since I'm writing the framework rather than importing a library, I've started out writing unit tests to exercise the static functions that generate the preview data, before I even have a working UI or even a working round trip client to server connection. This makes sure that I get the Swift generics right and that I'm building the things I think I'm building.

Strict test-driven-development (TDD) can be pretty obnoxious, especially if you're working on your own and not as part of a larger team. Frankly, strict anything is pretty obnoxious. However, when you're writing tests you need to remember that the test itself is not the point. The reason you write a test is so that you can have some confidence about a specific chunk of code. Therefore, my advice to anyone is, write tests as you write code, and make sure you run them often.


As Paul said you can't test everything and tests require upkeep like any other code so you want to be pragmatic about which ones and how much time you spend writing tests so that you can focus on adding new functionality

I'm a software engineer in testing and automation and for me the keyword is risk.

I would put the parts of your app into two categories...

  • The parts you absolutely can't risk being broken (i.e. would cause a user to delete your app in frustration)
  • The parts you are willing to risk not working (i.e. user will tolerate for the short term)

In my opinion once you have some key features and UI mostly in place the SwiftUI tests are a great way to get started thinking about testing because you can check that "happy paths" work from the user perspective. Failing UI tests are usually a symptom of some deeper code issue. After you investigate and fix that you can write a unit test for that area and develop an intuition about where you're doing that frequently for the future.

"Happy paths" in the Ultimate Portfolio app would be the things that Paul tested like adding and removing projects / items or renaming. As long as these key pieces of functionality work then you have a "happy" user who could accomplish that use case "path". However something like checking if all the awards are locked or assigning a color are nice but nobody will delete your application if these are not working.


Thanks everyone for the replies!


Hacking with Swift is sponsored by Emerge

SPONSORED Emerge helps iOS devs write better, smaller apps by profiling binary size on each pull request and surfacing insights and suggestions. Companies using Emerge have reduced the size of their apps by up to 50% in just the first day. Built by a team with years of experience reducing app size at Airbnb.

Set up a demo!

Sponsor Hacking with Swift and reach the world's largest Swift community!

Reply to this topic…

You need to create an account or log in to reply.

All interactions here are governed by our code of conduct.

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.