How many times in your career have you heard the phrase: “If it works, don’t change it”. That’s like saying I’m afraid of my code and fear is not a good way to drive your development. You are likely to change your code in the future while searching for a bug or adding a new feature, and you will probably be in a rush when doing it. If you want your code to allow fast changes, you will need to do refactors. The answer to how to eliminate the fear you feel when refactoring is testing.
That comes into play even harder with View Controllers, they are the gateway of the events that come from the user interface, the framework or other boundaries of our systems. We want to know that they are responding correctly to all these events. The VCs are also responsible for some logic like creating the instance of a view model according to the business logic, or validating the data introduced by the user using the interface. In a lot of systems the VCs are even responsible for implementing the flows of the interfaces by pushing other VCs to the UINavigationController associated with them.
This article is oriented to any developer that wants to find an easy, fast and reliable way to test the VCs of his system. Continue reading
To illustrate the posts I’ve created an iOS project on a Github repository where I implement examples.
Of course you have to consider it a demo. Some of the techniques explained in this blog are oriented to big projects that need to have his implementations decoupled and organized. They are not always useful for little projects like this demo. So don’t judge the code for this concrete case but as a picture of what I transmit through my posts.
From now on, every time I write a post, I will be updating this repository with example code that shows how to apply the theory. I’ll be happy to receive your feedback and what you think could be an improvement 🙂
Have you ever gone into a view controller and had the same sensation as you have when you enter a room after a huge party? It happened to me more than once. The last I saw was more than 1.600 lines long. How can you find anything inside? How can you test it, refactor it, change it or add new features?
Making our View Controllers lighter makes our life happier. Our applications have long lifetimes and we will have to read the code we write a lot of times. The problem is that when we start to learn how to develop for the iOS platform using Apple’s examples, we get used to having a lot of things inside the VC classes. Business logic, database, view logic, …
This first post talks about how we can separate our view logic from the view controller. As a usual practice we get the view controller to create and/or control all the hierarchy of the view (using xib or loadView method). We make the VC aware of all the little details of the view like the layout, the animations, how to fill it, respond to every event of the subviews… That makes the VC harder to understand, and very coupled on how the view is showed.
Hi, my name is Jordi Pellat. I’m a software engineer and I’ve been working with iOS platform the last 4 years of my career. Actually I’m working at Tuenti, a mobile operator creating the Telco 2.0.
Nowadays we create very complex and extensive apps, our code bases has hundreds or even thousands of classes, but I lack of blogs speaking on how to coexist with this fact. I open this blog to share my ideas with other developers and learn the weaknesses and improvements others can provide.
How can we improve our systems? With good architectures, testing techniques and good local software design. Sometimes we take the blame to the iOS framework because it leads us to a bad design or to have parts of our system untested. I will show the techniques I learn through books, colleagues and experience to face this problem.
Let’s be the owners of our code and not the opposite!