-
Notifications
You must be signed in to change notification settings - Fork 352
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
Introduce test_specification
DSL
#369
Conversation
33f0b21
to
448f753
Compare
* None. | ||
* Introduce `test_specification` DSL | ||
[Dimitris Koutsogiorgas](https://github.com/dnkoutso) | ||
[Kyle Fuller](https://github.com/kylef) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the work was done so I included the credit.
# end | ||
# | ||
def test_spec(&block) | ||
subspec = Specification.new(self, 'Tests', true, &block) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benasher44 do you think we should force the name to always be 'Tests'
or let podspec authors to configure it? This means that each spec (including root) can have 1 and only 1 test spec right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid future DSL gotchas: it's worth considering about making sure a test target can be configured to support multiple test targets, for example you might have unit tests + uiintegration tests (we do in Eigen, but we don't in any of our libs FWIW)
You might not have to do the work today, but building the DSL in a way that supports that is 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@orta good point. Having a test spec is one thing but there is no way to configure it to generate a UI test target or a unit test target. Do those differ much?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They differ considerably in implementation (one is a bundle injected into an app target, the other an app target)
Additional cool thing could easily be a small plugin command that generates the xcodeproj for developers. This means a developer can clone a repo and through the podspec generate the xcodeproj to develop on the pod. This means no more xcodeproj checked in to the repo which means no more ugly conflicts. |
c91dfa4
to
0464159
Compare
# @param [Bool] all_platforms | ||
# whether the dependencies should be returned for all platforms | ||
# instead of the active one. | ||
# @param [Platform] platform |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed documentation for this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really good start, excited for this to land 👍
# end | ||
# end | ||
# | ||
def test_spec(&block) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should maybe be:
def test_spec(name = 'Tests', type = :unit, &block)
or similar to allow for extension into different test target types in the future.
Will rebase and resume this a bit this weekend. still high on my radar for 1.3.0. |
278c88b
to
ff2bf56
Compare
@spec = Spec.new do |spec| | ||
spec.name = 'Spec' | ||
spec.test_spec do |test_spec| | ||
test_spec.test_type = :unit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added it in the initializer of Specification.rb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed it now as the attribute now has a default_value
set when used with a consumer.rb.
This looks like what I'd expect it to look like 👍 |
9d7a63c
to
fab2c45
Compare
I think its ready! |
5e55185
to
08dc711
Compare
# | ||
# @param [Symbol] type | ||
# The test type to use. | ||
attribute :test_type, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead the Linter
takes care of validating the value is correct, which I added a test for.
cc50e76
to
6ecbf89
Compare
# @param [Symbol] type | ||
# The test type to use. | ||
attribute :test_type, | ||
:default_value => :unit, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out this exists!
Very excited for this |
👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merging! Lets this party started. |
I'd like to re-open the "project" for adding test support to CocoaPods.
We have 100s of projects that we typically end up having to include a
<ProjectName>Tests.xcodeproj
that includes all of our test sources and aPodfile
that integrates it with the pod locally.I've chatted with @orta and @benasher44 on bringing this back. It would be awesome for podspecs to become more self-contained and when consumed as development pods the
Pods.xcodeproj
can create a test bundle target to include test sources so you can run them.We are also heavy users of development pods in our main project causing us to create multiple xcodeproj just to support our tests for pods we will never publish which also complicates CI further.
This is the first PR that brings back the DSL to include a
test_spec
.We won't be going super advanced on this to begin with. Test specs should create a test bundle target in the Pods.xcodeproj and include the test sources. The validator should also be updated to run the tests if a
test_spec
is present before publishing a pod. If notest_spec
is specified everything should continue to work the way it is today.