-
Notifications
You must be signed in to change notification settings - Fork 403
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
Create a full test #79
Comments
I can work on this. I would create a repository that would become CocoaPods/pod-template-tests It would include several folders like How would we test this? Can we create a .travis.yml file in this pod-template repo which is related to testing the template, rather than templating the test? This would have upstream breaking impact on cocoapods, is that ok? |
The vendored end results can be done as a submodule in the pod-template repo, we have a tool for doing this in CocoaPods itself called CLIntegracon which will get you most of the way TBH. This is how it is run in CocoaPods I don't think it would need any changes to the |
Note: this is implemented in #179. It uses Rake and runs a test suite of the vendoring process against expected outcomes. |
We should have a repo which is the result of pod-template which specific arguments. Then a test that runs though the same options and then does a diff on output.
Similar to https://github.com/QueryKit/mogenerator-template/blob/master/Makefile#L7-8. We don't need any complex ruby, simple diff does the job.
This should give us more visibility on the output and how it looks, and also allows us to know when we unintentionally break something.
The text was updated successfully, but these errors were encountered: