Hi,

Thank you for raising your issues. The 
StringCompareUtil.equalsIgnoreLineSeperator (good typo catch), is used to 
handle potential problems with the formatted output ending up with a 
different line-ending due to running the tests on different platforms than 
the expected output was generated on. There may be better solutions to 
this.

Speaking for SSE's components, since these were mentioned in particular, I 
don't think there has been any official review of style for these test 
cases. Additionally, a lot of these test cases are very old. I think we're 
always happier to see at least some test cases included with new 
contributions rather than none at all. We'd certainly love to have 
high-quality tests, and any contributions towards getting us there would 
be appreciated. With the number of tests that we have, it would be a 
pretty big undertaking.

Thanks,
Nick



From:
<[email protected]>
To:
<[email protected]>
Date:
12/14/2013 01:10 PM
Subject:
[wtp-dev] WTP modules unit tests quality?
Sent by:
[email protected]



Hello,

I have opened a new bug on issues in the WTP's XML formatter unit tests: 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=424054. As I also noticed 
tests-related issues in the other WTP modules (projects), I decided not to 
write it to the bug itself, but this mailing list hopefully is a better 
target. So here it goes:

I noticed that the problematic 
StringCompareUtil.equalsIgnoreLineSeperator() (shouldn't it be sepArator?; 
mentioned in the bug) is used in other WTP modules (jsp, css, html) as 
well. So maybe the same problem there?

Next: Test classes across and even within different modules follow 3 or 
more naming conventions (even "*Tests" - which won't be executed, by 
default, if you are ever about to use Maven (Tycho?), see 
http://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html
).

Another: Have somebody seen and reviewed classes like 
DOMImplementationTests or TestAttributesOrder? I know most people say 
"it's just test", but anybody having some practice in writing JUnit code 
must see the problems (repeated code, setUp() trying to be called just 
once by using non-static variable, ...). No offence, authors :)

I understand that these kind of problems are harder to be solved (code 
review? problematic on open source project?) and there are "real" bugs to 
be fixed but we should also bear in mind the long-term benefits (incl. 
attracting, or at least not dis-attracting, new possible contributors) 
when solving or warn about these issues. Hopefully the "production" code 
is treated better. What do you think?

Best regards

PB
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev



_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Reply via email to