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

Warn users that the object they're requesting holds has a key from a different bundle #57

Open
lalunamel opened this issue Mar 2, 2017 · 1 comment

Comments

@lalunamel
Copy link
Contributor

Given that you're writing a spec for a class under test (DogPicsViewController)

Given that you accidentally include ImageFetcher in your application target (DogPics) and your test target (DogPicsSpecs) that calls the main application it's host (DogPics is the host application of DogPicsSpecs)

Given than you inject a custom implementation (FakeImageFetcher) of a dependency of the class under test into the injector
[injector bind:[ImageFetcher class] toInstance: fakeImageFetcher]

Given that you ask for an instance of that class (ImageFetcher) in the class under test, either through bsinitializer or bsproperties

@interface DogPicsViewController
  @property (strong, nonatomic) ImageFetcher *imageFetcher;
@end

When the injector goes to grab the requested ImageFetcher for the class DogPicsViewController while running a spec, it will initialize a new instance of ImageFetcher even though you've faked out and bound an instance in your specs.

This happens because you've included your ImageFetcher in both your host application and spec bundles.

To somebody who hasn't already encountered this a few times, this behavior is totally impossible to figure out ("why's it not getting the thing I just bound? Aren't these two classes equal?")

The injector should warn the user that this is happening.

@lalunamel
Copy link
Contributor Author

We've thought of a couple ways to address this somewhere around https://github.com/jbsf/blindside/blob/master/Source/BSInjectorImpl.m#L149 but the solutions we've come up with are a bit complex and would make the code harder to reason about. Any thoughts?

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

No branches or pull requests

1 participant