Add packages config: increases mock generation speed (5x)
#548
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
LandonTClipp
changed the title
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## master #548 +/- ##
===================================================
+ Coverage 72.59201% 73.27982% +0.68780%
===================================================
Files 6 7 +1
Lines 1277 1744 +467
===================================================
+ Hits 927 1278 +351
- Misses 306 382 +76
- Partials 44 84 +40
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
TODO |
LandonTClipp
changed the title
packages config: increases mock generation speed (5x)
19 tasks
Mock generation speed is dramatically increased by specifying the packages to load in config instead of dynamically finding them. The issue with the previous logic is that a `package.Load` would be called once per file, even if multiple files were part of the same package. We can dramatically improve performance by giving a config file that states which packages should be generated. Add `with-expecter: True` Logic fixes
Restructuring config so that each object has its own set of config. This makes it easier to reason about which parts of the code are using which pieces of the config. Add config methods for parsing packages/interfaces Methods have been added that allows parsing of the complex `packages` config structure. Also adding large number of tests to assert it behaves as expected. Reshuffle the location of some code More additions: currently, mocks are failing to generate. All of the mocks are being given the name `foo`, and I'm not sure why. Next on the agenda is to figure that piece out and make the mocks have the correct struct names. Allow config to specify `configs` section This will let us specify multiple different mocks from the same interface. Work around issue with viper map parsing Viper throws away config with empty maps. Our config allows empty maps so we need additional logic to manually parse the `packages` section. add more tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Mock generation speed is dramatically increased by specifying the packages to load in config instead of dynamically finding them.
The issue with the previous logic is that a
package.Loadwould be called once per file, even if multiple files were part of the same package. We can dramatically improve performance by giving a config file that states which packages should be generated.#520
In this PR:
Previously:
Deprecations
When
packagesis defined:When
packagesis not defined:Configuration
You can see we have a configuration that looks like this for the mockery project:
This is extremely powerful as we can load in any Golang package we want, and we have fine-grained control over where it gets installed. The defaults are to install into the
mocksdirectory with a sub-path identical to the package's path (basically, we keep the same namespace as the go ecosystem).TODO
packagessection not including empty dicts. We want to "enable" an interface by simply specifying an empty dictionary.Type of change
Version of Golang used when building/testing:
How Has This Been Tested?
Ran mock generation manually and compared runtime to old method.
Checklist