Test framework in iOS development (reproduced)

CrespoXiao授权地址：http://www.jianshu.com/p/7e3f197504c1

Why should we use a test framework? Of course, the development of the project has helped, but the industry is often in progress, so TDD or forget it, BDD on the measurement of data access and important links, it is very important, one-time run test Unit check interface or module availability, which is more than the interruption of the debugging of the point, As for the UI test just forget it (xcode7 integration), hehe.

First look at the concepts of BDD and TDD:

BDD (Behavior Driven Development), or behavior-driven development, is designed to solve specific problems and help developers determine what should be tested.

TDD (Test-driven development)is a test-driven development that drives the entire development through testing.

On GitHub, you'll find TDD or BDD, with the 2 language choices Objective-c,star:

Https://github.com/kiwi-bdd/Kiwi/wiki

Https://github.com/specta/specta

There is also a test framework with less, called Cedar Https://github.com/pivotal/cedar

In addition, 2 Swift test frameworks have been found, which can be considered in the future with swift development:

Https://github.com/railsware/Sleipnir

Https://github.com/Quick/Quick

The 3 frameworks of Cedar,specta and Kiwi are the most popular BDD testing frameworks currently OBJC, where Kiwi is the most popular (based on the number of star numbers on GitHub, behavior descriptions and expectations are more understandable, at least I think).

However, the specta is maintained by the RAC people, and the black magic used for testing is more, and I'm afraid the people are too distracted to take this test framework into account. But some experienced people using the test framework chose to use the xctest, mainly because it is better integrated with Xcode, and the BDD framework is not able to hold the business development, Cmd+u can run all the tests at once (try 3 frames now can do so).

Xctest is deeply integrated with Xcode and can benefit from Apple's subsequent benefits for xctest upgrades. Xctest's strengths and weaknesses are due to its simplicity. You just need to create a class, using "test" as the prefix for the test method name, you just need to do it, no need to do anything else. Unfortunately, this is already the full advantage of xctest. The importance of the additional functionality of the BDD framework depends on the size of the project. My conclusion is that xctest is a good choice for small and medium-sized projects, but for larger projects it is necessary to refer to BDD frameworks such as Kiwi or specta. The difference between specta and Kiwi is that Kiwi contains all the functions of specta and Ocmock and Expeata. In other words specta is no mock and validation function Kiwi. Tested, kiwi and specta are not used in the project at the same time, will crash, do not believe you try, but each can be mixed with xctest because they are based on the Xctest package.

Cedar,kiwi, and specta provide similar syntax, I can't say that one of the frameworks is better than everything else, they have pros and cons, and the choice BDD framework boils down to personal preferences. I choose Kiwi is because only need to import a Kiwi in Podfile, specta need to rely on other third-party library, although flexible, but flexible has the disadvantage of flexibility, of course, there are benefits, you like it, anyway, don't resent me.

If you use Specta, you also need to introduce Ocmock/ocmockito and expeata/ochamcrest together with it.

Ocmock Or Ocmockito

These two are used to mock objects, the stub method, the difference between them is the use of Ocmock Cubby Ocmockito Library, and the documentation and tutorials richer.

Expecta Or Ochamcrest

Both are assertions of the extended framework, expecta immature, and the framework has some problems. Ochamcrest is more mature and scalable, and can customize its assertions and be more flexible.

The idea of BDD is that you're not writing code, you're telling a story. And the whole story was made by given ... When ... Then make up. Let's take a look at the test code for the BDD framework Kiwi:

describe(@ "Team" , ^{ context(@ "when newly created" , ^{ it(@ "has a name" , ^{ id team = [Team team]; [[team.name should] equal:@ "Black Hawks" ]; }); it(@ "has 11 players" , ^{ id team = [Team team]; [[[team should] have:11] players]; }); }); });

This test case is saying given a team,when newly created,it should has a name, and should have one players, basically do not need comments to know what to do.

Reference: http://onevcat.com/2014/05/kiwi-mock-stub-test/

Basic definitions of different types of mock objects:

Double can be understood as permutation, which is a general term for all simulated test objects, and we can call it an alias. In general, when you create any kind of test permutation object, it is used to override the object of a specified class.

Stub can be understood as a test pile, it can be implemented when a particular method is called, returns a specified analog value. If your test case requires a companion object to provide some data, you can use stubs to replace the data source, and you can specify that each consistent simulation data be returned when you test the settings.

The spy can be understood as reconnaissance, it is responsible for reporting the situation, keeping track of what methods were called, and what parameters were passed during the call. You can use it to implement test assertions, such as whether a particular method is called or whether it is called with the correct arguments. This is useful when you need to test some of the protocols or relationships between two objects.

A mock is similar to a spy, but slightly different in use. The spy tracks all method calls and lets you write assertions afterwards, while mocks usually require you to set expectations beforehand. You tell it what you expect to happen, then execute the test code and verify that the final result is consistent with the pre-defined expectations.

Fake is an object with full-featured implementation and behavior that behaves as if it were a real object of this type, but differs from the class it simulates, making testing easier. A typical example would be to use an in-memory database to generate a data persistence object instead of accessing a database of a real production environment.

In practice, these terms are often used differently from their definitions, or even interchangeable. They think of themselves as "mock object frames," but they also provide stub functionality and don't get too caught up in the details of these words.

The following talk about the use of Kiwi, as simple as possible, in order to quickly get started, of course, the details will have to read the official documents, linked to:

Https://github.com/kiwi-bdd/Kiwi/wiki

http://onevcat.com/2014/02/ios-test-with-kiwi/

Installation of 1.Kiwi

Write in Podfile

target  ‘OneTravelTests‘ , :exclusive =>  true  do pod  ‘Kiwi‘ end

Then pod install or pod update is available.

You can install a Xcode plugin Http://alcatraz.io with Kiwi template, install it, and then you can use Kiwi. However, some people say that plug-ins can not be used, blame me? Too lazy to explain, look here:

Https://github.com/cikelengfeng/RPAXU

Basic grammatical interpretation of 2.Kiwi

On 3 pictures, everything is in silence.

Kiwi Basic Grammar explanation

Mock and stub explanations

Test Data request

3. We should/should not test what

The first word of BDD shows this, you should not focus on testing, but should focus on behavior. This seemingly meaningless change provides an accurate answer to what should be tested: you should test the behavior.

For example, you design an object that has an interface that defines its methods and dependencies. These methods and dependencies, which declare the conventions of your objects, define how they interact with other parts of the application and what their functions are. They define the behavior of the object. It should also be your goal: to test how your object behaves.

What should not be tested?

Do not test private methods: Private methods mean private, if you feel the need to test a private method, then the private method must contain a conceptual error, usually as a private method, it does too much, thus violating the principle of single responsibility.

Do not stub private methods: Stub private methods and test private methods have the same harm, more importantly, the stub private method will make the program difficult to debug. In general, the library used for stubs relies on some unusual tricks to get the job done, which makes it difficult to find out why a test fails.

Do not test the constructor: the constructor defines the implementation details, and you should not test the constructor, because we agree that the test should be decoupled from the implementation details.

Do not Stub external libraries: third-party code should not appear directly in your tests.

4. Purpose of the test

Make refactoring easier-you can confidently modify implementation details without having to touch the public API.

Avoid code deterioration-when does the deterioration occur? When you change the code.

Provides executable instructions and documentation-when do you want to know how the software actually works? When you want to change them.

Reduced time to create software-how to reduce time? By modifying your code more quickly, the test will confidently tell you where it went wrong when something goes wrong.

Reduces the cost of creating software-time is money, friend.

The test should:

Very fast--tests should be able to be performed frequently.

can be isolated (Isolated)-the test itself cannot rely on external factors or the results of other tests.

Repeatable (REPEATABLE) – Each run of the test should produce the same results.

With self-test (self-verifying)-tests should include assertions that do not require human intervention.

Timely (timely)--the test should be written along with the production code.

5.UI Test

With regard to UI testing, the user's interaction needs to be tested, not the appearance of the app, and UI testing is added to the Xcode7, which can be seen in WWDC Session:406_hd_ui_testing_in_xcode.

Well, no, I have serious procrastination, hey.

For more information, please refer to: Http://www.objc.io

Test framework in iOS development (reproduced)