Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support library test bundles #13

Merged
merged 3 commits into from
Aug 28, 2018
Merged

Support library test bundles #13

merged 3 commits into from
Aug 28, 2018

Conversation

alanzeino
Copy link
Collaborator

...the library has historically been quite strict about enforcing that snapshots are run inside an Application test bundle with a Test Host. However as I discussed in the old repository, this can be relaxed for some cases:

facebookarchive/ios-snapshot-test-case#235

* `UIWindow` — You cannot make a `UIWindow` you created during your test the 'key window' because `makeKeyAndVisible` crashes at test run time. One workaround is to instead set `hidden` to `false` on the `UIWindow` instance you created. However there still won't be a 'key window' so if you have code that adds a `UIView` as a subview of the `keyWindow` then that will break.

### Library tests
Unit tests that test parts of a framework or libary should be part of a Library test bundle. This does not require a Test Host or a Simulator (though in Xcode 9, Apple still launches a Simulator for these tests).
Copy link

@bielski bielski Feb 7, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libary -> library

" host sets up a key window at launch (either via storyboards or programmatically) and doesn't"
" do anything to remove it while snapshot tests are running."];
}
NSString *message = @"Snapshot tests should be hosted by an application with a key window. Please ensure your test host sets up a key window at launch (either via storyboards or programmatically) and doesn't do anything to remove it while snapshot tests are running.";

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why to log this message if keyWindow exists? Maybe you should keep it in if statement?
Also, you didn't update a comment in a header file about raising an exception.
(not sure if this method should still contain strict word in the name...)


### Application tests

Unit tests that test parts of an application (such as UIViewControllers, UIWindows, UIViews) should typically be part of an Application test bundle. An Application test bundle requires a Test Host and at test run time, a Simulator too.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Library tests also need to be run in the context of a simulator to access ios sdk specific API's. The increased functionality that the test host gives is an app context, which provides access to api's around app/viewcontroller lifecycle, functionality requiring entitlements.

* `-[UIControl sendActionsForControlEvents:]` — This API is commonly used to trigger actions at runtime and sometimes you might want to use it inside a test to trigger a particular code path which is ordinarily run when a user performs an action. While it does not work inside a Library test bundle, [we've written our own version for unit tests](FBSnapshotTestCase/Categories/UIControl+SendActions.h) that works well for this need. If you decide to use that category, make sure it can only be seen inside unit tests and not all of your code.
* `UIAppearance` — Most `UIAppearance` APIs break when there is no test host present.
* `UIWindow` — You cannot make a `UIWindow` you created during your test the 'key window' because `makeKeyAndVisible` crashes at test run time. One workaround is to instead set `hidden` to `false` on the `UIWindow` instance you created. However there still won't be a 'key window' so if you have code that adds a `UIView` as a subview of the `keyWindow` then that will break.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we also had some tests requiring keychain access that needed to be run with a test host.

@alanzeino alanzeino force-pushed the libraryvsapplication branch from 0581324 to 71bbf33 Compare August 28, 2018 17:29
@alanzeino alanzeino merged commit c17aa0b into master Aug 28, 2018
@alanzeino alanzeino deleted the libraryvsapplication branch August 28, 2018 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants