Comments (5)
Workaround: replacing Cedar's spy_on
with OCMock no longer produces a crash.
id dateMock = OCMClassMock([NSDate class]);
OCMStub(ClassMethod([dateMock date])).andReturn(fakeTodayDate);
from cedar.
spy_on
also does not work for other Foundation classes like NSData and NSDictionary.
from cedar.
Hello @aaa-abrowne ! Thanks for writing up such a clear issue, you've made it really easy for me to understand at a high-level what's happening.
If you're curious, I'm fairly sure this is happening because the core of Cocoa and Foundation is slowly being rewritten in swift. Cedar makes the assumption that anything it spies on is a proper objective-c object, and spying on Swift objects is not supported. The impressive objective-c shim that exists does a good job of hiding the work Apple is surely doing here, but it's inevitable things like this will happen as Apple slowly starts changing the core of Foundation and other frameworks.
All that aside, I think this is really unlikely to be fixed. Even knowing that OCMock supports it, I think that's highly undesirable. In terms of best use of mocking frameworks, something you'll hear occasionally is the precept "Don't mock types you don't own", or stated in other words "Only mock interfaces that you have defined yourself in your proper application. Do not mock external interfaces". You can find this discussed in much detail on the internet if you'd like to learn more about this element of using mocks.
Additionally, I'd consider an NSDate
to be a value type. It's a nice type that encapsulates a timestamp and has methods for operating on that date. It's effectively a really nice wrapper around an integer that is interpreted as a date. Given that, I'd like to share that it's not considered a good practice to mock "value types" - you can find some additional articles on this subject as well.
In terms of how to best apply mocks and spies in an Objective-C or Swift codebase, I haven't ever found a lot of materials (I'd love to write a blogpost on this topic) but I did find a great discussion on StackOverflow that is really aligned with the solutions I've found helpful in my codebases in the past.
Using solutions where you define the needs of your objects in terms of the domain specific messages and data they need, rather than directly using the built-in classes provided by Apple can help you arrive at solutions that are more flexible, easier to test, easier to understand, although they can be perceived as less idiomatic occasionally (although I don't personally find that to be such a bad thing. Idiomatic does not mean "best solution" in my opinion).
All that said, I'd like to try to find a reasonable way to resolve your problem. It looks like in this stack trace, it failed because you have some mocked NSDate
s and then you add them to an NSSet
, which fails because NSSet
assumes they will respond to the -hash
selector, although it does not. I think it could be useful if Cedar were to emit a warning if you spied on a class that started with the "NS" prefix, or certain other prefixes that are known to be used by Apple. This warning could link to a wiki page here that has some of this information I've shared and tell you that this will soon become an error. I could imagine in a future release this could become an error, and Cedar would (by default) refuse to spy on these classes, because of the potential for this problem.
What are your thoughts on such a solution ? Do you feel such a warning with helpful messaging around what to do here would help you to write better tests ?
from cedar.
Thanks for the timely response. We're currently supporting legacy code that extensively uses spy_on
on Foundation and UIKit objects. A warning would be helpful to guide better practices.
from cedar.
Cool thanks for the quick response @aaa-abrowne. There's an outside chance that I may have contributed to some of those spying practices on Foundation and UIKit objects, so if that's true I beg your eternal forgiveness for the sins I have committed against best practices.
I will say, while I was writing this up, I was reflecting on some of the challenges we face (as TDD practitioners that practice good OO hygiene) while attempting to use the richness of Cocoa in a codebase with tests. The sheer convenience of methods on classes such as NSDate
really make it harder to see when these problems are occurring. It's only come with time and experience that it's been obvious to me at a glance that an NSDate
is a value type, and as such, shouldn't be mocked. The fact that the API is so rich and very quickly gives you complicated behaviors (often from a singleton class using its static methods) makes it hard to consider whether a collaborating object would be useful, since it often obfuscates what is going on.
Probably something to think about when working in a codebase with rich usage of Foundation
and UIKit
.
Out of curiousity, are there any other Apple frameworks that you are using that would be useful to avoid mocking ? I've used the PassKit
and CoreLocation
frameworks a lot in the past, and I don't think I would ever want to mock out anything from there, for example.
from cedar.
Related Issues (20)
- Console output is logged out of order HOT 1
- new project can't find cedar HOT 1
- Xcode 7.3 beta 5 errors on __weak in manual reference counting HOT 6
- Use of @import HOT 2
- Custom matchers fails to compile using Xcode 7.3 HOT 4
- Test observation issues HOT 2
- Weak References in XCode 7.3 HOT 4
- Playground support
- Installing template fails on AppCode 2016.1 HOT 1
- Cedar silently accepts misuse of the test structure DSL
- Running Individual Specs HOT 9
- Cedar, Swift and Protocol Declarations - Compiler error HOT 7
- testing watchOS with Cedar and Swift
- Cedar Standalone with XCode 8/ios-sim 5.0.8 HOT 4
- Cedar needs a sticker. HOT 4
- should equal throws exception when comparing const pointer to a non-const pointer HOT 5
- Cedar status HOT 1
- Xcode 9 compatibility HOT 8
- [Known Issue] Cedar's test specs cannot be folded in Xcode 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cedar.