Unit Testing & TDD Training for Mobile Apps
11 likes581 views
- The document provides an agenda and overview for a training on unit testing and test-driven development for iOS and Android native apps. - It covers unit testing concepts like the definition of a unit test, test properties, test structure for different platforms, naming conventions, verification types, and using test doubles. - Test-driven development is explained as a process of writing tests before code to drive the design. The core TDD process involves adding a test, seeing it fail, writing minimum code to pass the test, and refactoring. - Guidelines for object-oriented design that facilitates testing are presented, including dependency injection, single responsibility principle, loose coupling, and favoring composition over inheritance.
Unit Testing & TDD Training for Mobile Apps
- 1. Unit Testing & TDD Training For iOS & Android Native Apps
- 2. Agenda - Part 1: Unit Testing Concepts - Part 2: Test-Driven Development - Part 3: Object Oriented Design for Testing
- 4. Unit Testing Definition - A unit test is code made to test a portion of our applications code in an automated manner, verifying methods functionality (result or behavior) of a particular class (SUT or System Under Testing).
- 5. Unit Tests Main Properties - Independent - Running a UT should not affect another UT run. Execution order is not important. - Fast - A test which takes several seconds to run is not a Unit Test and probably needs a refactor. - Isolated - UT should not depend on external systems. They need to know their collaborators answers.
- 6. Test Class Structure - Class Setup/TearDown - Executed once when the UT class is initialized, not for every test in the class. Useful to avoid test code duplication at class level. - Test Setup/TearDown - Executed once before and after each executed UT. Useful to avoid test code duplication at test level. - Test Methods - The Unit Test implementation itself. Here is where the test run and validations happens.
- 7. Android Test Structure Example (Java)
- 8. iOS Test Structure Example (Swift)
- 9. Tests Naming - Use descriptive test names. It will provide quick feedback when test fails. - Avoid prefix “test” when no required by framework. Android JUnit does not need it, XCTest require it. - Choose names which in few words says: - Method under testing - Condition under testing - Expected result/behavior
- 10. Tests Naming Examples - Good examples: - Android: getPayments_oneRegisteredPayment_returnsListWithRegisteredPayment - iOS: testListPayments_oneRegisteredPayment_returnsListWithRegisteredPayment - Bad examples: - testCalculateArea2 - testCalculateArea3
- 11. Test Method Organization - Arrange / Setup - Prepare all needed objects/dependencies for test execution. - Act / Test - Test itself it performed, calling one specific method in the system under testing. - Assert / Verify - Method result/behavior verification is performed at the end, using test asserts.
- 12. Tests Verification Types - State Verification - Verify the result returned for the method under test, no matter which interactions with other objects has been made. Useful and preferred verification in most cases. - Behavior Verification - Verify that all tested method interactions among other collaboration objects are the expected one (generally done using mocks). Useful for some cases where interactions are important (for example a cache implementation).
- 13. Android State Verification Example (Java)
- 14. iOS State Verification Example (Swift)
- 15. Test Doubles - Dummy - Fake - Stubs - Mocks
- 16. Test Doubles - Dummy - These are objects used to satisfy class dependencies, but they are not used in the test execution itself. For example Java constructor or Swift init dependencies for class instantiation. - Fake - Objects with functional implementation, but with useful shortcuts for testing. For example an in-memory database, which works but after a test run lost all stored data.
- 17. Test Doubles - Stubs - Objects with pre-programmed replies. They are not prepared to respond to another thing more than what they were programmed for. Useful in tests for state verifications. - Mocks - Pre-programmed objects with expectations, which are requirements about it use, like: way to be called, invocations amount, invocations parameters. Useful in tests for behavior verifications.
- 18. Android Behavior Verification Example (Java - Mockito)
- 19. Android Behavior Verification Example (Java - EasyMock)
- 20. iOS Behavior Verification Example (Swift)
- 22. What TDD is? ● It is a software development process driven by tests. ● It consist in first write one or more unit tests of a class yet to be implemented, then write the minimum necessary code to make that test pass. ● Each Unit Test represents a requirement for that class. ● Each Unit Test keeps and evaluates the developer's knowledge about that class over time. ● It avoids unnecessary code complexity not specified by a particular requirement.
- 23. What TDD is not? ● It is not a testing technique. ● It is not write a class first and then write tests to have a good code coverage. ● It is not functional tests, it must be quickly executed and must not have dependencies with external systems.
- 24. The TDD process - Step 1 Add a new unit test, that represents a requirement for a method of a class.
- 25. The TDD process - Step 2 Execute the test and expect it to fail. In cases when the test don't fail, this means that the requirement has been fulfilled before. Go back to step 1 and add a new unit test for a new requirement.
- 26. The TDD process - Step 3 Implement the method in the class, to make the new unit test successfully pass.
- 27. The TDD process - Step 4 Execute all the unit test suite, making sure that all the previous test successfully pass. If some tests fail, fix the implementation that make those tests fail. Remember to re execute the test suite every time the code has been changed.
- 28. The TDD process - Step 5 Improvements and cleaning code, this can be made without worries about breaking something because the test suite gives us immediate feedback if some test fails
- 29. TDD Process in a nutshell 1. Add a new test 2. Execute the test 3. Add the least amount of code necessary to make that test pass 4. Execute the whole test suite 5. Refactor and clean code
- 30. Tips ● Any development can be faced using TDD starting with an interface with the signature of the methods to be implemented and tested. ● One single person can be in charge to implement the tests and other person can be in charge to implement the class methods. ● An alternative to avoid the interface is to define the class with its method by simply throwing an exception indicating that the method has not yet been implemented.
- 31. Object Oriented Design for Testing
- 32. Dependency Injection - Allows that dependent objects needed in our class implementation can be specified (injected) from outside of that class. - This can be done using constructors/initializers or properties.
- 33. Dependency Injection - Using Constructor (Java)
- 34. Dependency Injection - Using Initializer (Swift)
- 35. Dependency Injection - Using Setter (Java)
- 36. Dependency Injection - Using Property (Swift)
- 37. Single Responsibility - Each class should have a single responsibility. - Reduces coupling of different domain functionalities. - Facilitates classes reusage. - The opposite of having Utils/Helper classes. These classes hardly have a unique responsibility.
- 38. Single Responsibility - Examples - Bad Example: - Good Examples: StringUtil +isValidDate(String) +parseDate(String) +translateString(String) DateParser +isValidDate(String) +parseDate(String) TranslationService +translateString(String)
- 39. Don’t talk to strangers (1) - An object only should invoke methods of direct known dependencies. - Avoid calling dependencies of our dependencies (strangers). This is avoid chain of methods in code.
- 40. Don’t talk to strangers (2) - It’s a guide, not a rule. For example this could be avoid in model/entities objects. - Reduces object coupling, improving code maintainability and allows refactor when needed.
- 41. Don’t talk to strangers - Examples - Bad Examples: Java: this.paymentService.getStorageService().getStoredObject(paymentId) Swift: self.paymentService.storageService.storedObjectWithId(paymentId) - Good Examples: Java: this.paymentService.getPayment(payement) Swift: self.paymentService.paymentWithId(paymentId)
- 42. Tell don’t ask - Objects should tell another objects to perform actions instead of asking for data and processing the data itself. - Objects should be as lazy as possible and delegate the processing to its dependencies. - Improves class testability and class cohesion.
- 43. Tell don’t ask - Examples - Bad Example: - Good Example: ShapeService -shapes : List<Shape> +calculateTotalArea() : float Rectangle <Shape> +getHeight() : float +getWidth() : float ShapeService -shapes : List<Shape> +calculateTotalArea() : float Rectangle <Shape> +calculateArea() : float Shape +calculateArea() : float Circle <Shape> +getRadius() : float Circle <Shape> +calculateArea() : float Shape
- 44. Avoid Singletons - Singleton is a pattern that share a global state in the whole application. - In unit testing, does not allow dependencies control, because it hides class dependencies to the consumer. - Test execution order can affect the result of the test run when using singletons.
- 45. Avoid Singletons - Examples - Bad Example: - Good Example: PaymentService -storageService +PaymentService() StorageService <<Singleton>> -instance +getInstance() : Storage PaymentService -storageService +PaymentService(storageService) StorageService StorageServiceFactory +getStorageService() : StorageService MyApp -paymentService +execute() MyApp -paymentService - storageService +execute()
- 46. Questions?
- 47. Thank you so much!