Basic introduction to test-driven development in Swift

1. Making Software. Better.
Simple solutions to big business problems.
Test-Driven Development In Swift
by
@ameytavkar @javalnanda

2. Why do we test?

3. Why do we test?
● Confidence - Gain confidence in the system we are building.
● Verification - To verify what we create does what it’s supposed to do.
● Learning - Identify weak areas of the system.

4. Testing can be done manually or
can be automated.

5. Why Automation?
● Faster Regression Tests - Automated tools run significantly faster than us.
● Easier Refactoring - Shortened feedback loops helps us to improve our design much
easily
● Continuous Integration - Having automated tests makes integration painless and
significantly faster.

6. Should we write our tests
before
or
after
implementation?

7. Why writing tests after implementation is bad?
● Laziness - Once the system is tested manually, writing unit tests seems like a extra
effort.
● Lack of Discipline - Code written without considering testing rapidly becomes tightly
coupled and makes it hard to refactor in later stages.
● Compromise - Tests are generally influenced by the written code instead of the actual
user requirements.

8. Why should we test first?

9. Why should we test first?
● Loosely Coupled Code - We tend to make our modules independent which in turn
helps in creating loosely coupled code.
● Verification - We write the tests keeping the requirements in mind.
● Confidence - We gain confidence that we won’t be breaking any functionality in the
process of implementing new ones.

10. Test-Driven Development (TDD)

11. What is TDD?

12. High test coverage is not the end
goal of TDD, it’s a side effect of it.

13. Test first
=
Thinking
+
Designing
+
Writing test

14. Live Demo

15. Tic Tac Toe Requirements
1. A marker can be placed on any empty space of a 3×3 board.
○ Game engine should be able to create a 3x3 board on initialization
○ Game engine should be able to place a marker on a board
○ Game engine should not be able to place the marker on an already placed marker
2. Two Players can take turns marking the spaces on the board.
○ Game engine should have 2 players on initialization
○ On start player one takes the move
○ After move game engine should toggle player turns

16. Common Pitfalls in TDD

17. Common Pitfalls in TDD
● Not Testing Behaviors - Test behaviors not implementations
● Having Dependencies - Avoid tests that depend on each other
● Not Refactoring on Green - Don’t jump ahead to next tests without checking the need
to refactor once you get a green for a test.

18. Common Pitfalls in TDD (Cont.)
● Poor Readability - Never ignore the importance of naming the tests correctly. Tests
are also executable requirement spec. Treat them well and try to name it relevant to the
behaviour you are testing.
● Large Tests - Avoid testing more than one behaviour in a single unit test.
● Not Respecting Privacy - Don’t violate scope just because you are not able to test
something. If it is hard to write the test, its a sign of code smell.

19. What not to test?
● Private Methods - This is an implementation detail and the tests for the exposed
methods should be sufficient enough to cover the private ones
● External Library/Framework - The framework should be tested by its own developer!
● UI Design - Constraints, Layouts should be part of UI Tests

20. Best Practises

21. Best Practises
● Use a good architecture
● Use protocols to isolate class to test
● Write structured tests - Arrange, Act and Assert
● Don’t start with edge cases
● Always work on one test case at a time
● Avoid writing redundant tests

22. How to test Controllers
● Move the non-UI specific logic code out of the viewcontrollers
● Use dependency injection to your advantage
● Use closures to your advantage

23. How to Mock Dependencies using protocols?
● Find the method/behavior definition(s) on the object that you need to confirm
interactions with
● Create your own protocol to duplicate the definition(s)
● Create a fake object that implements that the protocol
● Use the fake objects in your tests

24. Tools that we recommend
● Unit Tests
○ Quick / Nimble
‐ https://github.com/Quick/Quick
‐ Helps in forcing the developer to write more english-like statements
● UI Automation
○ EarlGrey
○ https://github.com/google/EarlGrey
○ Synchronized UI Tests!
● Mocking
○ Cuckoo
‐ https://github.com/Brightify/Cuckoo
‐ Auto-generate your mocks in swift!

25. Conclusions

26. Conclusions
● Automation Tests are our friends
● Testing before implementation forces us to think about design.
● TDD Mantra - RED -> GREEN -> REFACTOR -> REPEAT
● Test early, Test Often!
● TDD isn’t about tests, its about design
● We have loosely coupled and highly cohesive code by following TDD Mantra
● Gain Confidence in the system
● High Code coverage

27. Thank You
United Kingdom
+44 203 603 7830
helloUK@equalexperts.com
Equal Experts UK Ltd
30 Brock Street
London NW1 3FG
India
+91 20 6607 7763
helloIndia@equalexperts.com
Equal Experts India Private Ltd
Office No. 4-C
Cerebrum IT Park No. B3
Kumar City, Kalyani Nagar
Pune, 411006
Canada
+1 403 775 4861
helloCanada@equalexperts.com
Equal Experts Devices Inc
205 - 279 Midpark way S.E.
T2X 1M2
Calgary, Alberta
Portugal
+351 211 378 414
helloPortugal@equalexperts.com
Equal Experts Portugal
Avenida Dom João II, Nº35
Edificio Infante 11ºA
1990-083 Parque das Nações
Lisboa – Portugal
Thank You
USA
+1 866-943-9737
helloUSA@equalexperts.com
Equal Experts Inc
1460 Broadway
New York
NY 10036
LinkedIn
linkedin.com/company/equal-experts
Twitter
@EqualExperts
Web
www.equalexperts.com

28. References
1. http://www.netobjectives.com/blogs/why-test-driven-development-really-isn%E2%80%
99t-test-first
2. https://8thlight.com/blog/uncle-bob/2014/04/30/When-tdd-does-not-work.html
3. https://vimeo.com/68375232
4. https://github.com/javalnanda/good-tdd-stuff
5. https://blog.eliperkins.me/mocks-in-swift-via-protocols/