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

No java util date rule test #5

Merged

Conversation

FanJups
Copy link
Contributor

@FanJups FanJups commented May 14, 2019

Summary

java.util.Date is deprecated so I decided to add a new rule NoJavaUtilDateRuleTest.java and suggested other libraries :

  1. java.time ( java 8)

  2. java.util.GregorianCalendar

  3. java.Text.DateFormat

Details

  1. I created a new rule file src/main/java/ com.societegenerale.commons.plugin.rules.NoJavaUtilDateRuleTest.java and added a new String constant (NO_JAVA_UTIL_DATE_VIOLATION_MESSAGE) in src/main/java/com.societegenerale.commons.plugin.utils.ArchUtils.java

  2. I created src/test/java/com.societegenerale.commons.plugin.rules.NoJavaUtilDateRuleTestTest.java to test the rule and changed NumberOfRulesAvailable from 9 to 10 & totalClassesInPathWhenPackageFolderDoesNotExists from 12 to 13 in src/test/java/com.societegenerale.commons.plugin.rules.ArchUtilsTest.java

  3. I created 3 files ObjectWithJavaTextDateFormat.java ; ObjectWithJavaUtilDateReferences.java and ObjectWithJavaUtilGregorianCalendar.java in src/test/java/com.societegenerale.commons.plugin.rules.classesForTests

  4. I added my email in pom.xml

Context

  1. java.util.Date library is deprecated

  2. Use Java8 java.time or java.util.GregorianCalendar or java.text.DateFormat to parse and format dates instead of java.util.Date library because they support internationalization better

Checklist:

  • [x ] I've added tests for my code.
  • [x ] Documentation has been updated accordingly to this PR

Related issue :

Copy link
Contributor

@vincent-fuchs vincent-fuchs left a comment

Choose a reason for hiding this comment

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

Hi, thanks a lot for your first contribution to our project !!! It's much appreciated !!

please have a look at the comments I've provided. Also, please check the code formatting - a lot of the lines changed are actually only some formatting changes. We'll probably have to provide an automated code style check

ArchUtils.NO_JAVA_UTIL_DATE_VIOLATION_MESSAGE + " - class: "
+ methodCall.getOriginOwner().getName() + " - line: "
+ methodCall.getLineNumber()));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

code from lines 60-71 is not unit tested properly : I've commented it locally, and the tests are still passing. so please add a test for that use case, or remove that part of the code

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's a pleasure to contribute to this project. The source code format is automatically defined by Eclipse. I will also focus on these tests. Thanks for your idea.

List<JavaField> classesWithJavaUtilDateFields = item.getAllFields().stream()
.filter(field -> isJavaUtilDateField(field)).collect(toList());

for (JavaField field : classesWithJavaUtilDateFields) {
Copy link
Contributor

Choose a reason for hiding this comment

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

why do it in 2 steps ? instead of collecting the items, you could directly a foreach and add the violations in events

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great

}

@Test(expected = Throwable.class)
public void shouldThrowNoJavaUtilDateViolation() {
Copy link
Contributor

Choose a reason for hiding this comment

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

what's the added value of that test compared to previous one ? It's same, no ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You are right, I'll delete this second test.

I made some changes on NoJavaUtilDateRuleTest.java and  NoJavaUtilDateRuleTestTest.java about the tests and code style.
@FanJups
Copy link
Contributor Author

FanJups commented May 15, 2019

Thank you very much @vincent-fuchs , what do you think about the changes I've made ?

});
}

@SuppressWarnings("deprecation")
Copy link
Contributor

Choose a reason for hiding this comment

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

remove the SuppressWarnings annotation and modify your code so that no deprecation warning comes up.

@vincent-fuchs
Copy link
Contributor

Thank you very much @vincent-fuchs , what do you think about the changes I've made ?

Thanks for the changes, but there is still one thing I don't get :

  • I still don't see a test for
    item.getCodeUnits().stream().filter(codeUnit -> codeUnit instanceof JavaMethod)
    .flatMap(method -> method.getMethodCallsFromSelf().stream())
    .filter(method -> method instanceof JavaMethodCall)
    .filter(method -> isMethodUsingJavaUtilDateInternally(method)).forEach(methodCall -> {
    events.add(SimpleConditionEvent.violated(methodCall.getOriginOwner(),
    ArchUtils.NO_JAVA_UTIL_DATE_VIOLATION_MESSAGE + " - class: "
    + methodCall.getOriginOwner().getName()));
    });
    . I can still remove them, and no test is failing.

Also :

…TestTest.java / ArchUtilsTest.java / ObjectWithAdateField.java / ObjectWithJavaUtilDateReferences.java

NoJavaUtilDateRuleTest.java : 1) No method is imported using the java.util.Date library so I deleted code related to the cheking of imported methods  2) I created a constant  NO_JAVA_UTIL_DATE_VIOLATION_MESSAGE 3) I used SRC_CLASSES_FOLDER from ArchRuleTest

NoJavaUtilDateRuleTestTest.java :  I deleted ObjectWithJavaUtilDateReferences.java  and created ObjectWithAdateField.java

ArchUtilsTest.java : changed NumberOfRulesAvailable from 9 to 10 & totalClassesInPathWhenPackageFolderDoesNotExists from 16 to 17
@FanJups
Copy link
Contributor Author

FanJups commented May 20, 2019

@vincent-fuchs I applied new changes related to : NoJavaUtilDateRuleTest.java / NoJavaUtilDateRuleTestTest.java / ArchUtilsTest.java / ObjectWithAdateField.java / ObjectWithJavaUtilDateReferences.java

NoJavaUtilDateRuleTest.java :

  1. No method is imported using the java.util.Date library so I deleted code related to the cheking of imported methods

  2. I created a constant NO_JAVA_UTIL_DATE_VIOLATION_MESSAGE

  3. I used SRC_CLASSES_FOLDER from ArchRuleTest

  4. SuppressWarnings annotation is deleted

NoJavaUtilDateRuleTestTest.java : I deleted ObjectWithJavaUtilDateReferences.java and created ObjectWithAdateField.java

ArchUtilsTest.java : I changed NumberOfRulesAvailable from 9 to 10 & totalClassesInPathWhenPackageFolderDoesNotExists from 16 to 17

@vincent-fuchs vincent-fuchs merged commit fb6183b into societe-generale:master May 21, 2019
@vincent-fuchs
Copy link
Contributor

Thanks @FanJups ! We'll do a release soon, you'll be able to use it directly

@FanJups
Copy link
Contributor Author

FanJups commented May 21, 2019

Thanks @vincent-fuchs , that's great

FanJups referenced this pull request in FanJups/arch-unit-maven-plugin May 22, 2019
New rule added : no java util date (#5)
@FanJups FanJups deleted the no-java-util-date-rule-test branch May 28, 2019 12:54
vincent-fuchs pushed a commit that referenced this pull request Jul 31, 2019
adding "Official maintainers" section
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