So my first iOS app is nearly complete; by nearly complete, I mean it is a working app that I am using on a daily basis. I plan to use it for another two weeks or so, and see if can break any app feature in my daily usage. This is also a time when I have added every major feature to the app and what I do from time and again these days is a minor UI fix or optimise some of my earlier iOS code. You see, I started working on this app over a year ago and in that time, my knowledge of iOS programming has grown, I know more now, and I often find myself realising that there is certain code in my app that could be better written. So I go ahead with the re-write if it is nothing too major. One potential risk/side-effect of a minor UI fix or code optimisation is that I often end up breaking other app features.
What have I learned?
Well at this point I realise that had I written a bunch of unit tests in the beginning, testing the app after every minor fix or optimisation would have been much easier. So instead of manually testing every app feature after a few changes(just in case something was broken), I could just run a bunch of unit tests and see if it all fine. Amongst other things, you can have a read of this SO answer which explains the benefits of Unit Testing or get a more in-depth overview from this article or this.
So what's next?
Since I am using AngularJS for my app, one of the things on top of my list is to learn more about unit testing in AngularJS. This is a good source, or for my next app, I could adopt this approach, i.e. Test Driven Development i.e. TDD. Ohh and since all the"backend" code for my app is written in Swift, I could use one of the resources for unit testing in Swift from here.
p.s. for anyone who is going to jump on-board the, "doing something and breaking something else means badly written tightly coupled code" well, certain dependancies were simply unavoidable. The point of this post is really more along the lines of I only think like a developer when building things, I realise now that at times I should try to think like a tester. Writing unit tests, I reckon is one way to reinforce that mindset.
p.s. for anyone who is going to jump on-board the, "doing something and breaking something else means badly written tightly coupled code" well, certain dependancies were simply unavoidable. The point of this post is really more along the lines of I only think like a developer when building things, I realise now that at times I should try to think like a tester. Writing unit tests, I reckon is one way to reinforce that mindset.
Comments