I record all my tests in The snapshots are as big as the view being rendered. When Apple very subtly changed the font hinting in iOS 7.1, any snapshots with UILabels in them required re-recording.Įach snapshot is a PNG file stored in your repository, and together they average out at about 30-100kb per file for me. I tend to add a two-second wait for these tests.Īpple's OS patches can change the way their stock components are rendered. CATiledLayer-backed views require being on the main screen and being visible before they will render their tiles. If you write Auto Layout code a lot, then this is unintuitive. There are two notable examples that come to mind: Some UIView classes cannot be initiated without a frame in a test, so get into the habit of always giving a frame to your views to avoid these messages: : CGContextAddRect: invalid context 0x0. Alternatively, you can build your application code so that asynchronous code is run synchronously if flagged. This means you can give it 0.5 seconds to run, with the tests repeatedly being checked. Using testing frameworks like Specta or Kiwi provides ways of repeatedly running assertions in code until a timeout occurs or succeeds. This is a similar pattern throughout testing in Cocoa. View.backgroundColor = įBSnapshotVerifyView(view, perfect. UIView *view = initWithFrame:CGRectMake(0, 0, 80, 80)] Removing this will verify instead of recording There is a boolean property on the subclass recordMode that, when set, will make the macro record a new screenshot rather than check the result against a reference ORSnapshotTestCase : ORSnapshotTestCase The default behavior of Snapshots is to subclass FBSnapshotTestCase instead of XCTestCase, and to then use the macro FBSnapshotVerifyView(viewOrLayer, "optional identifier") to verify against an already recorded image. Running the command pod install will install the library. So installation is just adding pod "FBSnapshotTestCase" into the tests target of your Podfile. Let's not beat around the bush here: you should be using CocoaPods. Snapshots will also NSLog a command to the console to load the two images into the visual diffing tool, Kaleidoscope. All three images are put inside the application's tmp folder. When a test fails, it will generate an output image of the resulting visuals from the test, and an image of the visual difference between itself and the reference. Inside the test case folders are the reference images per test. Inside this is a library of folders based on the testcase class name. When it's set up, it will default to storing the reference images inside your project's Tests folder, in a subfolder called ReferenceImages. This makes it extremely quick, with my tests ranging from 0.013 to 0.086 seconds per image for fullscreen iPad and iPhone images on a MacBook Air. It makes the comparison by drawing both the view or layer and the existing snapshot into two CGContextRefs and doing a memory comparison of them with the C function memcmp(). Here is an example of a failing test where we have less grid items than expected in a view controller: When it fails, it will create a reference image of the failed test, and another image to show the difference of the two. This snapshot is used to create tests that compare a saved snapshot of the view/layer and the version generated by your test. View-based testing can be used to provide a high-level test covering a lot of use cases surrounding an object.įBSnapShotTestCase takes a UIView or CALayer subclass and renders it to a UIImage. Doing this means being able to ensure that different versions of your views, or different states of your views, continue to look the same. View-based testing means verifying that what the user sees is what you want the user to see. When Facebook released FBSnapshotTestCase to CocoaPods, I initially dismissed it for this reason. This gap in functionality means a lot of people dismiss writing tests due to the difficulty of doing view-based tests. There's Apple built-in support for logical testing of objects, but no support for testing the end result of view-based code. Writing tests for the visual aspects of an app is tricky. This article isn't to persuade you that you should do it, though in my opinion, you should. People have their own motivations to write tests for their applications.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |