Makes the gym tests much faster (26s -> 7s on my machine). It does this by limiting the number of times FastlaneCore::Project objects are instantiated and thus need to shell out to Xcode tools. A future improvement could be to separate the concern of testing Project class interactions with Xcode tools from downstream consumers like gym.
This caching is performed at the spec file level, so it depends on each spec file running against roughly the same project configuration for all of its tests. All of ours basically do! Also, the more test examples exist per file, the larger the savings.
This caching increases the complexity of a somewhat complicated code area by breaking some of the Configuration object sharing that happens internally so that side-effecting changes between Project and gym's config are shared. I'd consider it to be future work to try to reduce the tight coupling between Project objects and a tool's shared config object.
KrauseFx
commented
8 years ago
Makes the gym tests much faster (26s -> 7s on my machine). It does this by limiting the number of times
FastlaneCore::Projectobjects are instantiated and thus need to shell out to Xcode tools. A future improvement could be to separate the concern of testingProjectclass interactions with Xcode tools from downstream consumers like gym.This caching is performed at the spec file level, so it depends on each spec file running against roughly the same project configuration for all of its tests. All of ours basically do! Also, the more test examples exist per file, the larger the savings.
This caching increases the complexity of a somewhat complicated code area by breaking some of the
Configurationobject sharing that happens internally so that side-effecting changes betweenProjectandgym's config are shared. I'd consider it to be future work to try to reduce the tight coupling betweenProjectobjects and a tool's shared config object.