Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Test-Driven iOS Development with Swift 4 - Third Edition

You're reading from   Test-Driven iOS Development with Swift 4 - Third Edition Write Swift code that is maintainable, flexible, and easily extensible

Arrow left icon
Product type Book
Published in Oct 2017
Publisher Packt
ISBN-13 9781788475709
Pages 222 pages
Edition 3rd Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Dr. Dominik Hauser Dr. Dominik Hauser
Author Profile Icon Dr. Dominik Hauser
Dr. Dominik Hauser
Arrow right icon
View More author details
Toc

What to test

What should be tested? When using TDD and following the rules mentioned in the previous sections, the answer is easy--everything. You only write code because there is a failing test.

In practice, it's not that easy. For example, should the position and color of a button be tested? Should the view hierarchy be tested? Probably not; the color and exact position of the button is not important for the functioning of an app. In the early stages of development, these kinds of things tend to change. With the auto layout and different localizations of the app, the exact position of buttons and labels depend on many parameters.

In general, you should test the features that make the app useful for a user and those that need to work. The user doesn't care whether the button is exactly 20 points from the rightmost edge of the screen. All the user is interested in is that the button does what they expect it to and the app looks good.

In addition to this, you should not test the whole application in total using unit tests. Unit tests are meant to test small units of computation. They need to be fast and reliable. Things, such as database access and networking, should be tested using integration tests, where the tests drive the real finished application. Integration tests are allowed to be slow because they are run a lot less often than unit tests. Usually, they are run at the end of the development before the application is released, or they are run with the help of a continuous integration system each night on a server, where it doesn't matter that the complete test suite takes several minutes (or even hours) to execute.

You have been reading a chapter from
Test-Driven iOS Development with Swift 4 - Third Edition
Published in: Oct 2017
Publisher: Packt
ISBN-13: 9781788475709
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at R$50/month. Cancel anytime