On 25 Nov 2013, at 14:26, Szczepan Faber wrote:
Why shouldn't it work the same way? I don't see the value in
introducing
_another_ mechanism on top of includes/excludes other than
simplifying the
implementation. Introducing an extra mechanism seems like extra
complexity
for the user (i.e. what's the difference between test inclusion and
test
selection?).
Not sure. To me, it feels that there are 2 inputs: where are the tests
(e.g. physical location) and what tests to execute (regexp on methods
/
classes, classes of type X, classes with certain annotations, some
runtime
conditions etc.).
This distinction seems completely artificial to me. It's to the same
end.
Moreover the physical location is just a coarser and less capable
version of your latter.
All of that said, backwards compatibility may force our hand here.
But, I
still think we should try hard to avoid adding new concepts.
Exactly right.
So we are admitting defeat here on the backwards compatibility angle?
That is, there's no way to make include/exclude more powerful to meet
these new requirements?
I'm not hardcoded on --only, just couldn't come up with anything
better
under current circumstances. Perhaps my reasons are not strong enough
we
can go ahead with --include?
We can only use --include if it's just a way to add a test.include
pattern
from the command line. If the semantics are different in any way we
can't
use it.
Agreed. In this case, the semantics are different (we want to specify
the
method).
Again, artificially I think. I don't think we've fully shaken out that
we can't collapse these concepts.
It's undecided yet how to specify multiple only tests but we might
allow
something like:
gradle --only FooTest,BarTest,BazTest.xxx
Cheers!
On Sat, Nov 23, 2013 at 5:36 PM, kelemen
<attila.keleme...@gmail.com>
wrote:
I'm with Luke in this case regarding the separator character. Two of
the
benefits of '#':
- Test method calls and test classes are easily distinguishable by
looking
at them.
- Using "." will leave the user wonder: "How does it know I'm
referring
to a
method?" which could be a source of misunderstanding.
By the way, using "::" instead of "#" would be consistent with Java
8
notation (not that it is really that important).
To me however, it is more important that I can start the test method
from
the command line and a clear (unambigous) syntax would be better
here. I
believe why it is mostly needed is to (re)test a single method when
something is broken (and is assumed to be fixed) which is not a
predefined
set of test methods. Although probably there are good cases for the
predefined set of methods (to group quicker tests, etc.).
--
View this message in context:
http://gradle.1045684.n5.nabble.com/supporting-the-execution-of-a-particular-test-method-tp5711996p5712039.html
Sent from the gradle-dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Szczepan Faber
Principal engineer@gradle; Founder@mockito
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Szczepan Faber
Principal engineer@gradle; Founder@mockito
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
