TDD in Swift

Getting started with Test-Driven Development in Swift

Transcript

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/