iOS Code Testing Abhishek Mishra PDF Download - Programming Ebook


Download Programming Ebook

Facebook Page

Monday, July 3, 2017

iOS Code Testing Abhishek Mishra PDF Download

iOS Code Testing

Book Details 
             TitleiOS Code Testing
         Author: Abhishek Mishra
     Publisher: Abhishek Mishra
    Language: English
        SubjectSwift / Computers & Technology / Programming / Apple Programming
No. of pages: 449
         Format: PDF

iOS Code Testing

Test-Driven Development and Behavior-Driven Development with Swift 

Introduction to Test-Driven Development

Well over a billion apps have been developed for the iOS platform since its inception. Most of the early apps were rather simple and often developed by a single developer. Over the years, iOS apps have become increasingly complex pieces of software that often involve large, distributed teams of developers working in Agile environments with complex build and release pipelines.

Modern apps often perform several complex operations including (but not limited to) presenting a complex user interface, multithreading, storing data in local databases, interfacing with multiple sensors, media recording and playback, and consuming RESTful web API’s.

Download Begin IOS 10 Book

With such a complex interplay between components of an app and several thousand lines of source code spread across several hundred classes, how do we know for certain that the code we have written does what we think it does? How do we know that our code can handle edge scenarios? And finally, how do we know that we have built the right software that meets business requirements? The answer to the first two questions is addressed by the practice of unit testing, and Behavior-Driven Development (BDD) addresses the answer to the question of building the right software in the first place. BDD is covered in Chapter 10. In this chapter and the next one you will learn about unit testing, and the related discipline of Test-Driven Development (TDD).

What Is Test-Driven Development?

Test Driven Development (TDD) has its roots in a programming paradigm called Extreme Programming1 (XP), created by Kent Beck in 1996. The use of the word “extreme” signifies a radical departure from standard programming practices of that time.

TDD is designed to provide developers with a tangible way to prove that the code they have written does what they think it does, and to provide some confidence that the new code that has been written does not cause any potential side effects with existing code.

Central to the TDD approach is the concept that a developer not only writes actual code to carry out the app’s functionality but also tests code that ensures his application’s code does what it is supposed to do. The test code is not shipped with the product.

While writing test code in addition to code that carries out the app’s intended functionality is indeed extra work, it should be seen as an up-front investment toward improving the quality of the product that ships to customers. A team that practices TDD techniques will, over time, observe a reduction in the number of regression defects.

Note tdd is often used interchangeably with the term unit test; however, these two terms are not the same thing. tdd is an approach to software development where the test code is written first: in essence, the tests drive development.

A unit test is just a piece of test code viewed in isolation. A unit test is one of the by- products of adopting a TDD approach.

However, the mere existence of one or more unit tests does not necessarily imply that the developer followed a TDD approach. The unit tests could, for instance, have been fitted retrospectively to existing code.

If you find working on large problems overwhelming, you may find TDD to be a useful technique to break down a problem into smaller ones, use tests to solve the smaller problems, and in the process end up solving the larger problem. You will soon realize that large problems are not as overwhelming once you approach them with a TDD mindset.

TDD Terminology

This section examines some of the common terminology associated with Test-Driven Development.

Subject under Test

This is usually a piece of code, or unit of functionality you wish to test. In most situations the subject under test is usually a single method of a Swift class. However, you may encounter scenarios where a small group of methods or classes are being tested together. In such cases, the subject under test usually represents a complete functionality or user journey. The subject under test is sometimes also known as the system under test.

Unit Test

This is the piece of code that tests the subject under test. A unit test is also known as a “test case.” Unit tests work by calling the subject under test under controlled conditions, and verifying some kind of expected behavior. It is common for an application to have hundreds of unit tests with each test testing a very small piece of the functionality.

Individual unit tests are implemented as independent methods of a Swift class that derives from an XCTestCase. This Swift class is also commonly referred to as a test class.

In most cases you will create one test class for each class you wish to test. The XCTestCase class is part of the XCTest framework, and the framework must be imported with an import statement. The following code listing contains a simple test class with one unit test:
import XCTest

@testable import LoginService
class LoginServiceTests: XCTestCase {
    func testExample() {
        // insert test code here.

Note the code that forms these unit tests is not part of the code base that will ship to the clients. unit tests are typically executed every time a developer attempts to create a build, with the build being created only if all tests pass.

The method signature of a unit test is similar to that of a method that takes no arguments and does not return a value. However, the name of a unit test method always begins with the keyword “test.” There are usually strict naming conventions followed for unit test methods; these will be discussed in the next lesson.

State Verification Test

A state verification test is a type of unit test that calls methods on an object (subject under test) and verifies the state of the object after calling the method. Such tests do not care about implementation detail and will continue to pass even if the internal workings of the methods being tested are changed in the future. State verification tests usually rely on assertions to carry out the actual verification. Assertions are covered later in this lesson.

Interaction Test

An interaction test is a type of unit test that attempts to verify a specific sequence of interactions between objects when a method is called. Such tests are also known as behavior verification tests. Interaction tests do not necessarily have to involve multiple objects. You could also use an interaction test to verify the sequence of calls to methods of the same object.

In a complex object-oriented system, a single object may need to interact with several other objects when a method is called. When it comes to interaction tests, the subject under

test is still a single class, and not the entire group of classes. One typically instantiates the subject under test and uses special mock or stub versions of all the other objects involved in the scope of the interaction test. Mock and stub objects are covered later in this lesson.

Note since interaction tests verify the behavior of a group of classes, they are inherently more fragile than state verification tests. For instance, a change in the order in which methods are called could easily break an interaction test. one way to make interaction tests less brittle is by reducing the number of classes covered by the scope of the test. 

No comments:

Post a Comment