Details
Improvement
Open
Major
Description
... in that case the Java method that it pertains to could provide the matching expression:
@Given
public void aUserWithALargeBankBalance { .. }
would be equiv to
@Given("a user with a large bank balance") public void aUserWithALargeBankBalance { .. }
or maybe we could endorse Ruby naming conventions for extra capitalization clarity:
@Given
public void a_user_with_a_large_bank_balance { .. }
Obviously this is no good for cases where there are parameters. Though that could be solved too later, with yet more work.
Guilherme Silveira's idea 
Activity
Mauro Talevi
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 3.1 [ 16511 ] | |
| Description |
... in that case the Java method that it pertains to could provide the matching expression:
| @Given | public void aUserWithALargeBankBalance { .. } would be equiv to | @Given("a user with a large bank balance") | public void aUserWithALargeBankBalance { .. } or maybe we could endorse Ruby naming conventions for extra capitalization clarity: | @Given | public void a_user_with_a_large_bank_balance { .. } Obviously this is no good for cases where there are parameters. Though that could be solved too later, with yet more work. Guilherme Silveira's idea :) |
... in that case the Java method that it pertains to could provide the matching expression:
{code} @Given public void aUserWithALargeBankBalance { .. } {code} would be equiv to {code} @Given("a user with a large bank balance") public void aUserWithALargeBankBalance { .. } {code} or maybe we could endorse Ruby naming conventions for extra capitalization clarity: | @Given | public void a_user_with_a_large_bank_balance { .. } Obviously this is no good for cases where there are parameters. Though that could be solved too later, with yet more work. Guilherme Silveira's idea :) |
We can definitely do that, although it would only be useful when there are no parameters.
But let's not go chasing conventions other than Java's. In the end steps classes are Java POJOs.
Show
Mauro Talevi
added a comment - We can definitely do that, although it would only be useful when there are no parameters.
But let's not go chasing conventions other than Java's. In the end steps classes are Java POJOs.
Mauro Talevi
added a comment - We can definitely do that, although it would only be useful when there are no parameters.
But let's not go chasing conventions other than Java's. In the end steps classes are Java POJOs. Mauro Talevi
made changes -
| Summary | @Given, @When and @Then could make the string optional .... | @Given, @When and @Then could make the pattern optional |
Just noted the comment on the fact that one could also consider the case of parameters. Don't see how, unless one goes into all sort of strange conventions. I think that would complicate a model which is at present quite simple and allow a nice separation between the pattern and the method name.
Show
Mauro Talevi
added a comment - Just noted the comment on the fact that one could also consider the case of parameters. Don't see how, unless one goes into all sort of strange conventions. I think that would complicate a model which is at present quite simple and allow a nice separation between the pattern and the method name.
Mauro Talevi
added a comment - Just noted the comment on the fact that one could also consider the case of parameters. Don't see how, unless one goes into all sort of strange conventions. I think that would complicate a model which is at present quite simple and allow a nice separation between the pattern and the method name. Mauro Talevi
made changes -
| Description |
... in that case the Java method that it pertains to could provide the matching expression:
{code} @Given public void aUserWithALargeBankBalance { .. } {code} would be equiv to {code} @Given("a user with a large bank balance") public void aUserWithALargeBankBalance { .. } {code} or maybe we could endorse Ruby naming conventions for extra capitalization clarity: | @Given | public void a_user_with_a_large_bank_balance { .. } Obviously this is no good for cases where there are parameters. Though that could be solved too later, with yet more work. Guilherme Silveira's idea :) |
... in that case the Java method that it pertains to could provide the matching expression:
{code} @Given public void aUserWithALargeBankBalance { .. } {code} would be equiv to {code} @Given("a user with a large bank balance") public void aUserWithALargeBankBalance { .. } {code} or maybe we could endorse Ruby naming conventions for extra capitalization clarity: {code} @Given public void a_user_with_a_large_bank_balance { .. } {code} Obviously this is no good for cases where there are parameters. Though that could be solved too later, with yet more work. Guilherme Silveira's idea :) |
Mauro Talevi
made changes -
| Fix Version/s | 3.2 [ 16757 ] | |
| Fix Version/s | 3.1 [ 16511 ] |
Mauro Talevi
made changes -
| Fix Version/s | 3.x [ 16979 ] | |
| Fix Version/s | 3.2 [ 16757 ] |
I would love to see that... I can probably come up with other nasty suggestions soon... all for CoCs sake