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

Whitespace Control with New Line Trimming Disabled Tests #477

Merged
merged 10 commits into from
Oct 19, 2019

Conversation

nward1234
Copy link
Contributor

I added tests for whitespace control for templates when New Line Trimming is disabled. Also added assertj and commons-io Maven dependencies for use in the tests. Commons IO is used to compare template output to expected output that is loaded from a file. Loading the expected template output from a file is useful for testing multiline template output, which is necessary to test various scenarios. These are a form of Integration Test rather than Unit Tests and so it is practical and reasonable to verify the template output in this way.

Related issue: #470 (comment)

…ng is enabled. Also added assertj and commons-io Maven dependencies for use in the tests. Commons IO is used to compare template output to expected output that is loaded from a file. Loading the expected template output from a file is useful for testing multiline template output, which is necessary to test various scenarios. These are a form of Integration Test rather than Unit Tests and so it is practical and reasonable to verify the template output in this way.
…hanged the test method names in some cases to make the purpose of each test method more clear.
@ebussieres
Copy link
Member

@nward1234 build is failing

@nward1234
Copy link
Contributor Author

nward1234 commented Sep 28, 2019 via email

@nward1234
Copy link
Contributor Author

nward1234 commented Sep 28, 2019 via email

@nward1234 nward1234 closed this Sep 28, 2019
@nward1234 nward1234 reopened this Sep 28, 2019
@nward1234
Copy link
Contributor Author

Cool! Closed and reopened so that Travis build would kick off again and the build passed.

<!-- https://mvnrepository.com/artifact/org.assertj/assertj-core -->
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
Copy link
Member

Choose a reason for hiding this comment

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

do you really need assertj for your tests ? I'd like to stick with minimal dependencies

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since I see that we have Hamcrest matchers, I would not mind using the Junit org.junit.Assert.assertTha() with Hamcrest Matchers instead of AssertJ. However, I would rather use AssertJ because it is more readable than Hamcrest, although either is much more readable than JUnit alone. AssertJ also is easier to use than Hamcrest because the fluent methods allows IDEs to provide method autosuggestions whereas you have to know the Matcher class names and include static imports for each Hamcrest matcher.

Would you say more about the reason for sticking with minimal dependencies? I'd like to understand your concerns.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Eric. I see that you merged the pull request. Did you decide that you are OK with the additional AssertJ dependency? If not, let me know and I will change it. I would like to hear more about why minimal dependencies is important to you. I plan to make more tests and hope to continue contributing to Pebble. So, I would like to understand your concerns and I want to be sure that you are fine with my changes.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah i'm ok with assertJ. I personnaly use it too. I just don't want to have a lot of unit tests made with differents libraries (some with google truth, others with assertj or junit or hamcrest, etc)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah! Now, that makes sense. I certainly can understand and agree with that. I think that we should have some standards like this. We can always decide to change the standard and then migrate to the new standard overtime when there is a reason to do so. At some point soon, I would be glad to replace the small amount of Hamcrest Matchers used in the code and standardize on AssertJ. I would not mind also using AssertJ where JUnit eventually, but I would think that would be a lower priority. I would also be glad to start documenting coding standards as needed. It would be just documenting existing standards that aren't down on paper yet so people know up front. In any case, I'll continue using AssertJ and get started on the larger task of addressing the whitespace control issues.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It appears that your standards indentation is 2 characters in Java code. I can live with that if that is your standard. However, I'd like to confirm that you prefer 2 characters. I'm used to 4 characters for Java, which is the default for Eclipse. I know that Javascript is typically 2 characters, but I have never seen 2 characters used for Java before. So, I just wanted to confirm that you want it to be 2 characters. If so, I will continue with 2 characters, which is what I have done in my changes so far to be consistent with the existing code.

Copy link
Member

@ebussieres ebussieres Oct 20, 2019

Choose a reason for hiding this comment

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

@ebussieres ebussieres added this to the 3.1.1 milestone Oct 19, 2019
@ebussieres ebussieres merged commit 40b722d into PebbleTemplates:master Oct 19, 2019
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.

2 participants