Skip to content
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

Implementation of "Filler Words" #472

Merged
merged 1 commit into from
Jun 23, 2020
Merged

Conversation

richard-stowe
Copy link

Hi @janschaefer and @l-1squared.

I have the first PR ready. In addition to the new @FillerWord concept I've also added @Punctuation, let me know what you think?

Richard

import java.util.Collections;
import java.util.List;
import java.util.Optional;
import java.util.Set;
import java.util.Stack;

import static com.google.common.collect.Iterables.concat;
import static com.google.common.collect.Iterables.getLast;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we start introducing google.common.collect as static import, all used methods should be imported statically and the imports in line 5 and 6 should be removed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Muscle memory pulled in the static imports. I've reverted this and aligned new usages of google.common.collect with the previous implementation

append( word, " " );
}

public void append( CharSequence word, CharSequence delimiter ) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not entirely certain, if having a generic method is the best approach here. From my understanding we have to classes of things to add here: Words and Punctuation. As I see it words should always be appended with space, punctuation always without. Admittedly there are special characters like [(" where that might not be true, but I don't think they are really supported.
Hence my suggestion is to have two method appendWord and appendPunctuation that always add the input with or without whitespace respectively.
In my opinon this would make is easier for readers to understand the usage of the methods.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've incorporated your suggestion

@@ -159,6 +171,18 @@ public void introWordAdded( String value ) {
introWord.setValue( value );
}

private void fillerWordAdded( String value ) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prefer addToFillerWords, because with this name, I always expect this to be a test that returns a boolean.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Addressed

return new PrintWriter( file, Charsets.UTF_8.name() ) {
@Override
public void println() {
write( "\n" );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is that better than the code of the standard PrintWriter class? Also, if there is a reason to circumvent the double checked locking in there, wouldn't you at least want to use this.lineSeparator instead of a hardcoded \n

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, this is something I quickly did to get the build working on my windows machine. I'll revert and look for something a little less "hacky"

public void a_pancake_can_be_fried_out_of_an_egg_milk_and_flour() {

given() .ingredients().comma() .consisting_of()
.asterisk() .an() .egg()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in this case, I'd argue that asterisk is functionally closer to a word than to punctuation. But I get now, why you implemented it the way you did. I'm just not completely satisfied...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, agreed. Maybe I overdid this one. I'll wind back the use of punctuation a little.

@richard-stowe richard-stowe force-pushed the filler-words branch 2 times, most recently from ffed081 to d0f5029 Compare June 18, 2020 07:57
l-1squared
l-1squared previously approved these changes Jun 18, 2020
docs/stages.adoc Show resolved Hide resolved
@l-1squared
Copy link
Collaborator

keeping this open for another day or say to give @janschaefer another opportunity to voice his opinion

@janschaefer
Copy link
Contributor

I think this is a great addition to JGiven, so thanks for that! I have two things:

  1. Have you verified that this works as expected in the HTML report as well?

  2. I personally had named the attribute punctuation of the FillerWord more technical. Something like: noWhitespace or just whitespace which is true by default. Because there might be situations in which you maybe have a filler word that is no punctuation and still want to have no white space.

@richard-stowe
Copy link
Author

@janschaefer, good point. I'm not completely sold on whitespace though, how about affix?

image

@richard-stowe richard-stowe changed the title Implementation of "Filler Words" and "Punctuation" Implementation of "Filler Words" Jun 19, 2020
@richard-stowe
Copy link
Author

HTML reports look good:

image

@richard-stowe richard-stowe force-pushed the filler-words branch 3 times, most recently from 124efeb to d475362 Compare June 19, 2020 10:59
@richard-stowe
Copy link
Author

@janschaefer, good point. I'm not completely sold on whitespace though, how about affix?

image

I've implemented this now. Let me know what you think.

@codecholeric
Copy link
Collaborator

codecholeric commented Jun 20, 2020

BTW: Those "addressing feedback", "rename x" of "fixed typo" commits I would squash onto the commits where the original change was introduced. Don't think they bring much value in the master history, right?

@l-1squared l-1squared self-requested a review June 23, 2020 05:05
Signed-off-by: Richard Stowe <richard.stowe@bt.com>
@l-1squared l-1squared merged commit 6df8c0e into TNG:master Jun 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants