1. The document discusses test-driven development (TDD) in Swift, including why it is important to write tests before implementation. Automated tests provide confidence, verification of requirements, and help identify weak areas of code. 2. TDD involves writing tests first to define requirements before writing any code. This forces developers to think about design and creates loosely coupled, independent code modules. 3. Common pitfalls to avoid in TDD include not testing behaviors, having dependent tests, not refactoring code, and testing private methods or external libraries. Best practices include using a good architecture, protocols to isolate classes, and structured tests with arrange, act, assert format.

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/