NEW: Learn to build amazing SwiftUI apps for macOS with my new book! >>

Ultimate Portfolio - General question about when to write tests

Forums > Articles

@cgaaf  

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)

1      

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.

2      

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.

2      

@cgaaf  

Thanks everyone for the replies!

1      

Hacking with Swift is sponsored by RevenueCat

SPONSORED Spend less time managing in-app purchase infrastructure so you can focus on building your app. RevenueCat gives everything you need to easily implement, manage, and analyze in-app purchases and subscriptions without managing servers or writing backend code.

Get Started

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

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

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.