Skip to content

Document the issue about linking Dependencies in the tests target #56

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Feb 27, 2023
Merged

Document the issue about linking Dependencies in the tests target #56

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
530eed6
Document the issue about linking `Dependencies` in the tests target.
tgrapperon Feb 27, 2023
36e26ee
Update Testing.md
stephencelis Feb 27, 2023
d18aff5
Update Testing.md
stephencelis Feb 27, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 20 additions & 1 deletion Sources/Dependencies/Documentation.docc/Articles/Testing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,8 @@ the updated dependency when run in the new `withDependencies` context.

## Testing gotchas

### Testing host application

This is not well known, but when an application target runs tests it actually boots up a simulator
and runs your actual application entry point in the simulator. This means while tests are running,
your application's code is separately also running. This can be a huge gotcha because it means you
Expand All @@ -122,7 +124,7 @@ running in a test context, and accessing dependencies will cause test failures.

This only happens when running tests in a _application target_, that is, a target that is
specifically used to launch the application for a simulator or device. This does not happen when
running tests for frameworks or SPM libraries, which is yet another good reason to modularize
running tests for frameworks or SwiftPM libraries, which is yet another good reason to modularize
your code base.

However, if you aren't in a position to modularize your code base right now, there is a quick
Expand All @@ -149,4 +151,21 @@ struct MyApp: App {
That will allow tests to run in the application target without your actual application code
interfering.

### Statically linking your tests target to `Dependencies`

If you statically link the `Dependencies` module to your tests target, its implementation may clash
with the implementation that is statically linked to the app itself. It then may use a different
`DependencyValues` base type in the app and in tests, and you may encounter test failures where
dependency overrides performed with `withDependencies` seem ineffective.

In such cases Xcode will display multiple warnings similar to:

> Class _TtC12Dependencies[…] is implemented in both […] and […].
> One of the two will be used. Which one is undefined.

The solution is to remove the static link to `Dependencies` from your test target, as you
transitively get access to it through the app itself. In Xcode, go to "Build Phases" and remove
"Dependencies" from the "Link Binary With Libraries" section. When using SwiftPM, remove the
"Dependencies" entry from the `testTarget`'s' `dependencies` array in `Package.swift`.

[xctest-dynamic-overlay-gh]: http://github.com/pointfreeco/xctest-dynamic-overlay