On 11/1/07, aashish <aashish_tau17@...> wrote:
> Please assist me in mocking a static function of the source code in the
> testing code, when I cannot change the source code....
You could look into whether JEasyTest would do the trick for you:
https://jeasytest.dev.java.net
It does require AspectJ and I haven't tried JEasyTest myself but they
should be able to "redirect" static method calls to an alternative
implementation.
Lasse
--
Lasse Koskela
* Author of "Test Driven" (Manning Publications, 2007) *
* Reaktor Innovations * http://www.ri.fi/en *
aashish wrote:
> Please assist me in mocking a static function of the source code in the
> testing code, when I cannot change the source code....
If you have the ability to use dynamic languages, you can certainly
do this in Groovy and I would imagine Ruby (not sure). Otherwise,
you might want to consider JMockit (https://jmockit.dev.java.net/)
if you have the ability to run your tests on a Java 5 or 6 JVM.
Paul.
> --
> View this message in context:
> http://www.nabble.com/SetMock-in-Junit..-tf4729425.html#a13523500
> <http://www.nabble.com/SetMock-in-Junit..-tf4729425.html#a13523500>
> Sent from the JUnit - User mailing list archive at Nabble.com.
On 31/10/2007, pmcevoy12 <pmcevoy12@...> wrote:
>
> Hi,
>
> Is there a way to dynamically add tests to a test suite in JUnit 4?
>
> Maybe I am misunderstanding something, but it seems like the only way
> to add tests is via the @Suite.SuiteClasses{} annotation.
>
> In JUnit 3 I could do something like this
>
> public static Test suite() {
> TestSuite suite = new TestSuite();
> for (int i = 0; i < 100; i++) {
> suite.addTest(new MyTestCase(i));
> }
> return suite;
> }
>
> --- PM
Could you give us some more background on why you would want to do
this? I think I only ever used this feature for doing Parameterized
Tests, and JUnit 4 offers a different way of doing this, so I'd like
to understand a bit more about your use case before suggesting ways to
proceed.
Cheers,
James
On 01/11/2007, Paul King <paulk@...> wrote:
>
> aashish wrote:
> > Please assist me in mocking a static function of the source code in the
> > testing code, when I cannot change the source code....
>
> If you have the ability to use dynamic languages, you can certainly
> do this in Groovy and I would imagine Ruby (not sure). Otherwise,
> you might want to consider JMockit (https://jmockit.dev.java.net/)
> if you have the ability to run your tests on a Java 5 or 6 JVM.
>
> Paul.
>
If it's just a method that your code is calling, you could wrap it in
a simple Command interface and supply an implementation in your tests
that does what you want. If it's a method that's buried a little
deeper, then your workaround will get a little more complex. Lasse has
already suggested an AspectJ-based solution and I would second that
suggestion.
Cheers,
James
James,
I use the Java code as an algorithm and I put the actual parameters
into files on the file system.
For example, I might have these files
.../testdata/test1/input.xml
.../testdata/test1/output.xml
.../testdata/test2/input.xml
.../testdata/test2/output.xml
... and so on...
The TestSuite knows about the "testdata" directory. It loads a
TestCase for each "testX" directory (test1, test2, etc.). The TestCase
expects in the input and output files.
So, to add a new test, I just add a test3/input.xml and
test3/output.xml and I don't have to touch any Java code.
--- Patrick
--- In junit@yahoogroups.com, "James Abley" <james.abley@...> wrote:
>
> On 31/10/2007, pmcevoy12 <pmcevoy12@...> wrote:
> >
> > Hi,
> >
> > Is there a way to dynamically add tests to a test suite in JUnit 4?
> >
> > Maybe I am misunderstanding something, but it seems like the only way
> > to add tests is via the @Suite.SuiteClasses{} annotation.
> >
> > In JUnit 3 I could do something like this
> >
> > public static Test suite() {
> > TestSuite suite = new TestSuite();
> > for (int i = 0; i < 100; i++) {
> > suite.addTest(new MyTestCase(i));
> > }
> > return suite;
> > }
> >
> > --- PM
>
> Could you give us some more background on why you would want to do
> this? I think I only ever used this feature for doing Parameterized
> Tests, and JUnit 4 offers a different way of doing this, so I'd like
> to understand a bit more about your use case before suggesting ways to
> proceed.
>
> Cheers,
>
> James
>
A few weeks ago I wrote a blog
<http://www.artima.com/weblogs/viewpost.jsp?thread=215899> to introduce
Crap4J a prototype open-source tool that implements the C.R.A.P.
<http://www.artima.com/weblogs/viewpost.jsp?thread=210575> metric.
CRAP is designed to detect a particularly nasty and dangerous Java code
smell:
high complexity methods without adequate unit tests.
The concept behind CRAP is that code without tests is rarely a good
idea; but when you couple very complex code without adequate tests you
are really asking for it.
We did the original implementation of Crap4J as an Eclipse plug-in. The
response to Crap4J was so positive that we decided to go further and
created a dedicated website crap4j.org <http://www.crap4j.org> .
We've had hundreds of downloads since we launched the site, along with
many requests for Ant support and support for IDEs other than Eclipse.
We just added Ant support in 1.1.4, and we are planning to support other
IDEs like NetBeans and IntelliJ (BTW, if you are interested in
contribute to plug-in development please let us know).
If you have a chance, please try Crap4J on your project and let us know
what you think. We are interested in getting this group's feedback on
Crap4j and suggestions for improving and extending it.
The home page is: www.crap4j.org <http://www.crap4j.org> ; from there
you can navigate to the download page.
If you have any problems installing it or running it, feel free to ask
for help on the forum or file a bug report or feature request.
<http://trac.crap4j.org/>
Thanks,
Alberto
[Non-text portions of this message have been removed]
Patrick,
In JUnit 4, a skeleton for that might look like this:
@RunWith(Parameterized.class)
public class InputOutput {
private String inputFile, outputFile;
public InputOutput(String inputFile, String outputFile) {
this.inputFile = inputFile;
this.outputFile = outputFile;
}
@Test
public void io() {
assertResultOfInputIsOutput(inputFile, outputFile);
}
@Parameters
public static List<Object[]> files() {
return allFilesInTestFileDirectory();
}
}
Does that help?
David Saff
On 11/1/07, pmcevoy12 <pmcevoy12@...> wrote:
> James,
>
> I use the Java code as an algorithm and I put the actual parameters
> into files on the file system.
>
> For example, I might have these files
> .../testdata/test1/input.xml
> .../testdata/test1/output.xml
> .../testdata/test2/input.xml
> .../testdata/test2/output.xml
> ... and so on...
>
> The TestSuite knows about the "testdata" directory. It loads a
> TestCase for each "testX" directory (test1, test2, etc.). The TestCase
> expects in the input and output files.
>
> So, to add a new test, I just add a test3/input.xml and
> test3/output.xml and I don't have to touch any Java code.
>
> --- Patrick
>
>
> --- In junit@yahoogroups.com, "James Abley" <james.abley@...> wrote:
> >
> > On 31/10/2007, pmcevoy12 <pmcevoy12@...> wrote:
> > >
> > > Hi,
> > >
> > > Is there a way to dynamically add tests to a test suite in JUnit 4?
> > >
> > > Maybe I am misunderstanding something, but it seems like the only way
> > > to add tests is via the @Suite.SuiteClasses{} annotation.
> > >
> > > In JUnit 3 I could do something like this
> > >
> > > public static Test suite() {
> > > TestSuite suite = new TestSuite();
> > > for (int i = 0; i < 100; i++) {
> > > suite.addTest(new MyTestCase(i));
> > > }
> > > return suite;
> > > }
> > >
> > > --- PM
> >
> > Could you give us some more background on why you would want to do
> > this? I think I only ever used this feature for doing Parameterized
> > Tests, and JUnit 4 offers a different way of doing this, so I'd like
> > to understand a bit more about your use case before suggesting ways to
> > proceed.
> >
> > Cheers,
> >
> > James
> >
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
The only issue I have with this whole thing is the fact I might have to discuss
a
tool/metric called CRAP with management. A shame it isn't called a similarly
amusing but
less embarrassing name.
_____
From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
albsavoia
Sent: Friday, 2 November 2007 4:17 AM
To: junit@yahoogroups.com
Subject: [junit] Crap4j - Feedback and suggestions wanted
A few weeks ago I wrote a blog
<http://www.artima. <http://www.artima.com/weblogs/viewpost.jsp?thread=215899>
com/weblogs/viewpost.jsp?thread=215899> to introduce
Crap4J a prototype open-source tool that implements the C.R.A.P.
<http://www.artima. <http://www.artima.com/weblogs/viewpost.jsp?thread=210575>
com/weblogs/viewpost.jsp?thread=210575> metric.
CRAP is designed to detect a particularly nasty and dangerous Java code
smell:
high complexity methods without adequate unit tests.
The concept behind CRAP is that code without tests is rarely a good
idea; but when you couple very complex code without adequate tests you
are really asking for it.
We did the original implementation of Crap4J as an Eclipse plug-in. The
response to Crap4J was so positive that we decided to go further and
created a dedicated website crap4j.org <http://www.crap4j.
<http://www.crap4j.org> org> .
We've had hundreds of downloads since we launched the site, along with
many requests for Ant support and support for IDEs other than Eclipse.
We just added Ant support in 1.1.4, and we are planning to support other
IDEs like NetBeans and IntelliJ (BTW, if you are interested in
contribute to plug-in development please let us know).
If you have a chance, please try Crap4J on your project and let us know
what you think. We are interested in getting this group's feedback on
Crap4j and suggestions for improving and extending it.
The home page is: www.crap4j.org <http://www.crap4j. <http://www.crap4j.org>
org> ; from
there
you can navigate to the download page.
If you have any problems installing it or running it, feel free to ask
for help on the forum or file a bug report or feature request.
<http://trac. <http://trac.crap4j.org/> crap4j.org/>
Thanks,
Alberto
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
We discovered something disheartening from a testing standpoint: our
development and production environments are different in ways which can, and
do, change the manner of execution of our project. As such, we'd like to
run our unit tests as part of the execution of our final product, and not
just through our IDE.
We develop using Eclipse 3.3, using the JUnit4 plugin. We compile for
production and acceptance testing using the JET Excelsior ahead-of-time
compiler, which is Java SE 5 compatible. There are occasions when we have
run into SE6/SE5 compatibility problems but they had a tendency to cause the
compile to fail, not cause incorrect execution, so we didn't worry much
about it.
We started using the XStream XML serialization library. In its default mode
of operation, it actually tests to see what JVM and what libraries it is
running with to determine what execution mode it wants to run in -- with
certain JVMs, it can use different APIs for increased performance and
capabilities. In our development environment, it was able to run in
"enhanced mode" because it was using a recognized JVM (Sun Java 1.6). In
our production environment, it did not detect a "blessed" JVM, and ran in
"pure java mode". Our product passed all tests, but failed badly when
pushed to our Customer because our tests didn't catch that it wasn't in
enhanced mode.
I saw from the JUnit 4 API that it is possible to directly run a testrunner
on a class, invoking all the tests in the class. The @Suite.classes()
annotation (and the @RunWith annotation) allows one to make test suites
which consist of several classes, allowing one invocation of the testrunner
to cover all the classes in the suite. Those techniques seem suited to
allowing us to run the tests using our production JVM. But those seem to
require manual updating of the class lists in order to add new classes.
The problem is that we currently have over 500 tests, spread among many
classes in many packages. I see a maintenance nightmare using @
Suite.classes() because everytime we add a test class (which we do
routinely) we'd have to manually find a suite to add it to. I don't see a
way to conveniently say "for all classes in this package (or package
hierarchy), run the unit tests".
Is there a way to do what we want that isn't a maintenance nightmare?
[Non-text portions of this message have been removed]
Why can't you run your unit tests using JET Excelsior? Does the
ahead-of-time compiler remove reflection information that JUnit needs or
something?
And why did the acceptance tests not catch the error?
--Nat
On 01/11/2007, Buddha Buck <blaisepascal@...> wrote:
>
> We discovered something disheartening from a testing standpoint: our
> development and production environments are different in ways which can,
> and
> do, change the manner of execution of our project. As such, we'd like to
> run our unit tests as part of the execution of our final product, and not
> just through our IDE.
>
> We develop using Eclipse 3.3, using the JUnit4 plugin. We compile for
> production and acceptance testing using the JET Excelsior ahead-of-time
> compiler, which is Java SE 5 compatible. There are occasions when we have
> run into SE6/SE5 compatibility problems but they had a tendency to cause
> the
> compile to fail, not cause incorrect execution, so we didn't worry much
> about it.
>
> We started using the XStream XML serialization library. In its default
> mode
> of operation, it actually tests to see what JVM and what libraries it is
> running with to determine what execution mode it wants to run in -- with
> certain JVMs, it can use different APIs for increased performance and
> capabilities. In our development environment, it was able to run in
> "enhanced mode" because it was using a recognized JVM (Sun Java 1.6). In
> our production environment, it did not detect a "blessed" JVM, and ran in
> "pure java mode". Our product passed all tests, but failed badly when
> pushed to our Customer because our tests didn't catch that it wasn't in
> enhanced mode.
>
> I saw from the JUnit 4 API that it is possible to directly run a
> testrunner
> on a class, invoking all the tests in the class. The @Suite.classes()
> annotation (and the @RunWith annotation) allows one to make test suites
> which consist of several classes, allowing one invocation of the
> testrunner
> to cover all the classes in the suite. Those techniques seem suited to
> allowing us to run the tests using our production JVM. But those seem to
> require manual updating of the class lists in order to add new classes.
>
> The problem is that we currently have over 500 tests, spread among many
> classes in many packages. I see a maintenance nightmare using @
> Suite.classes() because everytime we add a test class (which we do
> routinely) we'd have to manually find a suite to add it to. I don't see a
> way to conveniently say "for all classes in this package (or package
> hierarchy), run the unit tests".
>
> Is there a way to do what we want that isn't a maintenance nightmare?
>
> [Non-text portions of this message have been removed]
>
>
>
[Non-text portions of this message have been removed]
Hi everyone,
Since we always advertise for various XP Days here, we'd like to give
something back that could be of interest to the members that did not
attend. We hope you find something of interest.
- http://xpdayna.stikipad.com/manhattan2007/show/
OpenSpaceSessionNotes# (Open Space wiki. Here, you'll find the
topics and associated notes that were posted and discussed during the
Open Space sessions at XP Day Manhattan)
- http://youtube.com/watch?v=viezJLrFRQE (A 7-minute clip of JB
Rainsberger's XP and Goldratt's Theory of Constraints talk, perhaps
his best version to date).
- http://xpdayna.stikipad.com/manhattan2007/show/SustainableCareer
(Slides of George Dinwiddie's Sustainable Career talk).
Sincerely,
Niraj.
--
Niraj Khanna
XP Day Co-Host & Promoter
XP Day North America
niraj@...
http://www.diasparsoftware.com
[Non-text portions of this message have been removed]
I just tried it some days ago.
I have some observations to share:
- the metric and the tool look promising :)
- I feel that in the current implementation, it is too forgiving.
Perhaps the percentage of crappy methods isn't the best indicator
(especially since, the way I understand it, this is loosing information
on *how* crappy the methods are).
- after running the tool, I wasn't able to delete the .agitar folder
(under Windows) until I restarted Eclipse
- I had a lot of tests throwing HeadlessExceptions, which surprised me.
Something strange with the runner?
Cheers, Ilja
--- In junit@yahoogroups.com, Ilja Preuss <it@...> wrote:
>
> I just tried it some days ago.
>
> I have some observations to share:
Hi Ilja, first of all, thank you for taking the time to try it and -
even more - for the feedback.
>
> - the metric and the tool look promising :)
>
Thanks
> - I feel that in the current implementation, it is too forgiving.
> Perhaps the percentage of crappy methods isn't the best indicator
> (especially since, the way I understand it, this is loosing information
> on *how* crappy the methods are).
For my personal tastes, the current settings are also too forgiving.
But when we experimented with tighter settings, a lot of people
complained that it was pointing out too many problems and that they
would pay more attention to it if it highlighted truly 'crappy' code.
> - after running the tool, I wasn't able to delete the .agitar folder
> (under Windows) until I restarted Eclipse
We'll look into it, but I believe that this is a common issue (Windows
does not want to delete a folder if it thinks Eclipse is using it.) I
assume you are able to delete it from Eclipse though.
> - I had a lot of tests throwing HeadlessExceptions, which surprised me.
> Something strange with the runner?
Oops, we'll look into that one. Feel free to file bugs directly if you
prefer: http://trac.crap4j.org/newticket
>
> Cheers, Ilja
>
Thanks again for taking the time Ilja.
Alberto
http://www.crap4j.com
Know your CRAP. Cut the CRAP. Don't take CRAP from nobody.
Why not just use its full name -- Change Risk Analysis and Predictions
-- when dealing with "management"?? And share the joke (CRAP) name for
your coworkers.
Wayne
On 11/1/07, Greg Irvine <greg.irvine@...> wrote:
> The only issue I have with this whole thing is the fact I might have to
discuss a
> tool/metric called CRAP with management. A shame it isn't called a similarly
amusing but
> less embarrassing name.
>
>
>
> _____
>
> From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
albsavoia
> Sent: Friday, 2 November 2007 4:17 AM
> To: junit@yahoogroups.com
> Subject: [junit] Crap4j - Feedback and suggestions wanted
>
>
>
>
> A few weeks ago I wrote a blog
> <http://www.artima. <http://www.artima.com/weblogs/viewpost.jsp?thread=215899>
> com/weblogs/viewpost.jsp?thread=215899> to introduce
> Crap4J a prototype open-source tool that implements the C.R.A.P.
> <http://www.artima. <http://www.artima.com/weblogs/viewpost.jsp?thread=210575>
> com/weblogs/viewpost.jsp?thread=210575> metric.
> CRAP is designed to detect a particularly nasty and dangerous Java code
> smell:
> high complexity methods without adequate unit tests.
> The concept behind CRAP is that code without tests is rarely a good
> idea; but when you couple very complex code without adequate tests you
> are really asking for it.
>
> We did the original implementation of Crap4J as an Eclipse plug-in. The
> response to Crap4J was so positive that we decided to go further and
> created a dedicated website crap4j.org <http://www.crap4j.
<http://www.crap4j.org> org> .
>
> We've had hundreds of downloads since we launched the site, along with
> many requests for Ant support and support for IDEs other than Eclipse.
>
> We just added Ant support in 1.1.4, and we are planning to support other
> IDEs like NetBeans and IntelliJ (BTW, if you are interested in
> contribute to plug-in development please let us know).
>
> If you have a chance, please try Crap4J on your project and let us know
> what you think. We are interested in getting this group's feedback on
> Crap4j and suggestions for improving and extending it.
>
> The home page is: www.crap4j.org <http://www.crap4j. <http://www.crap4j.org>
org> ; from
> there
> you can navigate to the download page.
>
> If you have any problems installing it or running it, feel free to ask
> for help on the forum or file a bug report or feature request.
> <http://trac. <http://trac.crap4j.org/> crap4j.org/>
>
> Thanks,
>
> Alberto
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
Hi, Alberto,
I've downloaded and run it on some code with which I work, and also
shown the results to some of my co-workers. I believe the idea is a
useful one (once they get past the name and the logo ;-).
I understand that this is a work in process, and therefore don't plan
to beat you up over exact coefficient and exponent values until I've
had some more experience with it myself. Thanks for taking the first
steps.
One question which I've heard multiple times is, "Now what?" I think
it would be great if the web site had content (even if wiki-mediated)
describing common patterns / code structures which cause a high
C.R.A.P. index and suggestions for corrective action. Many of my
co-workers don't spend their days thinking about cyclomatic complexity
and don't want to start by reading up on graph theory. Ergo a few
"case study" examples would be helpful, showing before-and-after code
where C.R.A.P. index drops and the resulting code is clearly more
maintainable.
Finally, I'd really like to be able to get more information on how the
testing measurement is derived (and the resulting side-effects). In
one project with lots of unit tests, including some which persisted
results to disk, the output directories were left in a state I did not
expect/understand. Knowing some of the basics here would be helpful to
someone who wants to take effective action as a result of the reported
index.
Again, thanks for your work on the tool. I hope to see more from it.
-jn-
--
Programming is the art of writing essays in crystal clear prose and
making them execute. - Per Brinch Hansen
The Eclipse plugin doesn't seem to work properly. I run it on a
project but no results are shown.
On 11/1/07, albsavoia <albsavoia@...> wrote:
>
>
>
>
>
>
>
> A few weeks ago I wrote a blog
> <http://www.artima.com/weblogs/viewpost.jsp?thread=215899> to introduce
> Crap4J a prototype open-source tool that implements the C.R.A.P.
> <http://www.artima.com/weblogs/viewpost.jsp?thread=210575> metric.
> CRAP is designed to detect a particularly nasty and dangerous Java code
> smell:
> high complexity methods without adequate unit tests.
> The concept behind CRAP is that code without tests is rarely a good
> idea; but when you couple very complex code without adequate tests you
> are really asking for it.
>
> We did the original implementation of Crap4J as an Eclipse plug-in. The
> response to Crap4J was so positive that we decided to go further and
> created a dedicated website crap4j.org <http://www.crap4j.org> .
>
> We've had hundreds of downloads since we launched the site, along with
> many requests for Ant support and support for IDEs other than Eclipse.
>
> We just added Ant support in 1.1.4, and we are planning to support other
> IDEs like NetBeans and IntelliJ (BTW, if you are interested in
> contribute to plug-in development please let us know).
>
> If you have a chance, please try Crap4J on your project and let us know
> what you think. We are interested in getting this group's feedback on
> Crap4j and suggestions for improving and extending it.
>
> The home page is: www.crap4j.org <http://www.crap4j.org> ; from there
> you can navigate to the download page.
>
> If you have any problems installing it or running it, feel free to ask
> for help on the forum or file a bug report or feature request.
> <http://trac.crap4j.org/>
>
> Thanks,
>
> Alberto
>
> [Non-text portions of this message have been removed]
>
>
--
Jason Rogers
"I am crucified with Christ: nevertheless I live;
yet not I, but Christ liveth in me: and the life
which I now live in the flesh I live by the faith of
the Son of God, who loved me, and gave
himself for me."
Galatians 2:20
--- In junit@yahoogroups.com, "Joel Neely" <joel.neely@...> wrote:
> I understand that this is a work in process, and therefore don't plan
> to beat you up over exact coefficient and exponent values until I've
> had some more experience with it myself. Thanks for taking the first
> steps.
Hi Joel, thank you for taking the time to try Crap4j and for having
the courage to present it to your colleagues despite its provocative
name :-).
We fully expect the metric and the formula to change and evolve as
people use it and gain experience with it. As you recognized, this is
just the first step.
> One question which I've heard multiple times is, "Now what?" I think
> it would be great if the web site had content (even if wiki-mediated)
> describing common patterns / code structures which cause a high
> C.R.A.P. index and suggestions for corrective action. Many of my
> co-workers don't spend their days thinking about cyclomatic complexity
> and don't want to start by reading up on graph theory. Ergo a few
> "case study" examples would be helpful, showing before-and-after code
> where C.R.A.P. index drops and the resulting code is clearly more
> maintainable.
Thank you for taking us to task on this one. Once I get done with my
official responsibilities at work this week, I'll take some time to
write an FAQ for the tool. In the meantime, I think that explaining
cyclomatic complexity as "too may ifs or loops" in a single method
might do the job.
> Finally, I'd really like to be able to get more information on how the
> testing measurement is derived (and the resulting side-effects). In
> one project with lots of unit tests, including some which persisted
> results to disk, the output directories were left in a state I did not
> expect/understand.
The only 'side effect' should be a directory/subdirectory containing
code coverage and complexity data + the files for the report
(including an index.html). You should be able to remove them anytime
from Eclipse.
>Knowing some of the basics here would be helpful to
> someone who wants to take effective action as a result of the
>reported index.
We are planning a quick web demo to show how to install and run
Crap4j, how to analyze the results and how to improve then. I plan to
have it before Thanksgiving.
> Again, thanks for your work on the tool. I hope to see more from it.
Thanks again for your for the feedback.
Alberto
Jason Rogers wrote:
> The Eclipse plugin doesn't seem to work properly. I run it on a
> project but no results are shown.
Worked fine for me.
Where the tests executed?
Cheers, Ilja
Joel Neely wrote:
> Finally, I'd really like to be able to get more information on how the
> testing measurement is derived (and the resulting side-effects). In
> one project with lots of unit tests, including some which persisted
> results to disk, the output directories were left in a state I did not
> expect/understand.
What I noticed is that the used runner executes several tests in
parallel. Perhaps your tests expect to be run serially?
--- In junit@yahoogroups.com, "Jason Rogers" <jacaetevha@...> wrote:
>
> The Eclipse plugin doesn't seem to work properly. I run it on a
> project but no results are shown.
Hi Jason,
Sorry you are having trouble. Here are some things you should
double-check:
1) Eclipse should be version 3.2.1 or later
2) JDK should be 1.4.x or 1.5.x - we haven't tested with 1.6
3) Did you select the project (i.e. top level icon in your code
hierarchy) before clicking on the Crap4J icon?
4) Does your project compile (i.e. no error) and run the tests you have?
Another thing you can try is to create another, very simple project to
see if the problem is with your project or with some strange
interaction between Crap4J and your Eclipse/other Eclipse plug-ins.
Here's something to try:
Create a new Java project (say "TestCrap4J" ). Eclipse should by
default create a source directory "src". Inside that directory create
a new class, say "Testing123". At this point you should have see a the
following in the Package Explorer view:
>TestCrap4J
[]src
[](default package)
[]Testing123.java
Click at the top level of the project (i.e. TestCrap4J) to make sure
the focus is on the project. Then click the toilet paper icon. You
should get a pretty barren crap4j report in a couple of seconds.
Please try that if you get a chance and let me know if get the report.
Another thing is to check the agitar directory in your project. It
should be there and it should contain the crap4j report in:
YourProject/agitar/reports/crap4j
If it's there, right click on index.html and open it Open With >
SystemEditor. The report should show up with your default browser.
albsavoia wrote:
> 2) JDK should be 1.4.x or 1.5.x - we haven't tested with 1.6
I've run it with 1.6, and didn't experience any problems besides the
HeadlessExceptions.
Cheers, Ilja
I just tried out the plug-in on some of my projects and the metrics look
interesting.
One quick suggestion: Some filtering functionality would be nice, perhaps just
the ability to exclude certain packages from the reports. Right now, one-shot
code that I know is crap, and already scheduled to be deprecated or deleted, of
course shows up at the top of the list. That makes it harder to spot the methods
that really need to be looked at.
/ Per
________________________________
From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On Behalf Of
albsavoia
Sent: Thursday, November 01, 2007 10:17 AM
To: junit@yahoogroups.com
Subject: [junit] Crap4j - Feedback and suggestions wanted
A few weeks ago I wrote a blog
<http://www.artima.com/weblogs/viewpost.jsp?thread=215899> to introduce
Crap4J a prototype open-source tool that implements the C.R.A.P.
<http://www.artima.com/weblogs/viewpost.jsp?thread=210575> metric.
CRAP is designed to detect a particularly nasty and dangerous Java code
smell:
high complexity methods without adequate unit tests.
The concept behind CRAP is that code without tests is rarely a good
idea; but when you couple very complex code without adequate tests you
are really asking for it.
We did the original implementation of Crap4J as an Eclipse plug-in. The
response to Crap4J was so positive that we decided to go further and
created a dedicated website crap4j.org <http://www.crap4j.org> .
We've had hundreds of downloads since we launched the site, along with
many requests for Ant support and support for IDEs other than Eclipse.
We just added Ant support in 1.1.4, and we are planning to support other
IDEs like NetBeans and IntelliJ (BTW, if you are interested in
contribute to plug-in development please let us know).
If you have a chance, please try Crap4J on your project and let us know
what you think. We are interested in getting this group's feedback on
Crap4j and suggestions for improving and extending it.
The home page is: www.crap4j.org <http://www.crap4j.org> ; from there
you can navigate to the download page.
If you have any problems installing it or running it, feel free to ask
for help on the forum or file a bug report or feature request.
<http://trac.crap4j.org/>
Thanks,
Alberto
[Non-text portions of this message have been removed]
I tried downloading it on my eclipse workspace couple of days back and
had a trail run against Commons Collection API. It did showed a
beautiful report with all the metrics in place, but I couldn't figure
out what they actually meant. Is there a documentation available on
how to understand these metrics ? I tried pondering around in your web
site but ended up finding some blog posts rather than any
documentation....
--- In junit@yahoogroups.com, "Wayne Fay" <waynefay@...> wrote:
>
> Why not just use its full name -- Change Risk Analysis and Predictions
> -- when dealing with "management"?? And share the joke (CRAP) name for
> your coworkers.
>
> Wayne
>
> On 11/1/07, Greg Irvine <greg.irvine@...> wrote:
> > The only issue I have with this whole thing is the fact I might
have to discuss a
> > tool/metric called CRAP with management. A shame it isn't called
a similarly amusing but
> > less embarrassing name.
> >
> >
> >
> > _____
> >
> > From: junit@yahoogroups.com [mailto:junit@yahoogroups.com] On
Behalf Of albsavoia
> > Sent: Friday, 2 November 2007 4:17 AM
> > To: junit@yahoogroups.com
> > Subject: [junit] Crap4j - Feedback and suggestions wanted
> >
> >
> >
> >
> > A few weeks ago I wrote a blog
> > <http://www.artima.
<http://www.artima.com/weblogs/viewpost.jsp?thread=215899>
> > com/weblogs/viewpost.jsp?thread=215899> to introduce
> > Crap4J a prototype open-source tool that implements the C.R.A.P.
> > <http://www.artima.
<http://www.artima.com/weblogs/viewpost.jsp?thread=210575>
> > com/weblogs/viewpost.jsp?thread=210575> metric.
> > CRAP is designed to detect a particularly nasty and dangerous Java
code
> > smell:
> > high complexity methods without adequate unit tests.
> > The concept behind CRAP is that code without tests is rarely a good
> > idea; but when you couple very complex code without adequate tests you
> > are really asking for it.
> >
> > We did the original implementation of Crap4J as an Eclipse
plug-in. The
> > response to Crap4J was so positive that we decided to go further and
> > created a dedicated website crap4j.org <http://www.crap4j.
<http://www.crap4j.org> org> .
> >
> > We've had hundreds of downloads since we launched the site, along with
> > many requests for Ant support and support for IDEs other than Eclipse.
> >
> > We just added Ant support in 1.1.4, and we are planning to support
other
> > IDEs like NetBeans and IntelliJ (BTW, if you are interested in
> > contribute to plug-in development please let us know).
> >
> > If you have a chance, please try Crap4J on your project and let us
know
> > what you think. We are interested in getting this group's feedback on
> > Crap4j and suggestions for improving and extending it.
> >
> > The home page is: www.crap4j.org <http://www.crap4j.
<http://www.crap4j.org> org> ; from
> > there
> > you can navigate to the download page.
> >
> > If you have any problems installing it or running it, feel free to ask
> > for help on the forum or file a bug report or feature request.
> > <http://trac. <http://trac.crap4j.org/> crap4j.org/>
> >
> > Thanks,
> >
> > Alberto
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
--- In junit@yahoogroups.com, Per Jacobsson <perjacobsson@...> wrote:
>
> I just tried out the plug-in on some of my projects and the metrics
look interesting.
>
> One quick suggestion: Some filtering functionality would be nice,
perhaps just the ability to exclude certain packages from the reports.
Right now, one-shot code that I know is crap, and already scheduled to
be deprecated or deleted, of course shows up at the top of the list.
That makes it harder to spot the methods that really need to be looked at.
> / Per
Hi Per, thank you for trying Crap4J, and thank you for your feedback.
The ability to exclude known crappy code is a popular request and we
are evaluating the cleanest way to do that. You can check the
following blog entry:
http://www.crap4j.org/news/?p=20
Thanks again for the feedback.
Alberto
--- In junit@yahoogroups.com, "edu_kumar" <sarat.beesa@...> wrote:
>
> I tried downloading it on my eclipse workspace couple of days back and
> had a trail run against Commons Collection API. It did showed a
> beautiful report with all the metrics in place, but I couldn't figure
> out what they actually meant. Is there a documentation available on
> how to understand these metrics ? I tried pondering around in your web
> site but ended up finding some blog posts rather than any
> documentation....
Hi Edu,
Thank you for trying Crap4j. We are in the process of adding
documentation (as well as demos) on the site. In the meantime, the
following Artima post should help you to get started:
http://www.artima.com/weblogs/viewpost.jsp?thread=215899
Thanks again for trying Crap4j and giving us feedback. Keep it coming...
Alberto
On Nov 6, 2007 1:01 AM, choweining <choweining@...> wrote:
> How do I enable the usage of JUnit 4.4 in Eclipse?
By adding the JUnit 4.4 jar file to your project's class path.
Lasse
--
Lasse Koskela
* Author of "Test Driven" (Manning Publications, 2007) *
* Reaktor Innovations * http://www.ri.fi/en *
--- In junit@yahoogroups.com, "edu_kumar" <sarat.beesa@...> wrote:
>
> I tried downloading it on my eclipse workspace couple of days back and
> had a trail run against Commons Collection API. It did showed a
> beautiful report with all the metrics in place, but I couldn't figure
> out what they actually meant. Is there a documentation available on
> how to understand these metrics ? I tried pondering around in your web
> site but ended up finding some blog posts rather than any
> documentation....
Hi Edu,
I posted a 6 minute video on YouTube that shows the basic usage of Crap4J.
The video quality is rather crappy (how appropriate) but hopefully the
basic idea comes across:
1) Run Crap4J.
2) See which method are considered CRAPpy (due to an bad combination
of complexity and lack of tests).
3) Cut the CRAP in those methods by a) adding tests or b) refactoring
overly complex methods.
I am exploring options for higher-resolution video, but in the
meantime you might want to check out this first attempt.
Here's the link to the YouTube video:
http://youtube.com/watch?v=bV6IhUh0IH4
Thanks,
Alberto
Hey Alberto,
I went through the article you pasted in your previous post as well as
the video in youtube. They're great and thanks for help, that really
resolved most of my questions I had in mind about crap4j.
Just in case if you're still on a look out for a 'Screen recording
Software', I know a open source tool which is a really good one. you
can try it yourself...
http://sourceforge.net/projects/camstudio/
Thanks and Regards.
kumar.
--- In junit@yahoogroups.com, "albsavoia" <albsavoia@...> wrote:
>
> --- In junit@yahoogroups.com, "edu_kumar" <sarat.beesa@> wrote:
> >
> > I tried downloading it on my eclipse workspace couple of days back and
> > had a trail run against Commons Collection API. It did showed a
> > beautiful report with all the metrics in place, but I couldn't figure
> > out what they actually meant. Is there a documentation available on
> > how to understand these metrics ? I tried pondering around in your web
> > site but ended up finding some blog posts rather than any
> > documentation....
>
> Hi Edu,
>
> I posted a 6 minute video on YouTube that shows the basic usage of
Crap4J.
>
> The video quality is rather crappy (how appropriate) but hopefully the
> basic idea comes across:
>
> 1) Run Crap4J.
> 2) See which method are considered CRAPpy (due to an bad combination
> of complexity and lack of tests).
> 3) Cut the CRAP in those methods by a) adding tests or b) refactoring
> overly complex methods.
>
> I am exploring options for higher-resolution video, but in the
> meantime you might want to check out this first attempt.
>
> Here's the link to the YouTube video:
>
> http://youtube.com/watch?v=bV6IhUh0IH4
>
> Thanks,
>
> Alberto
>
Hi Alberto.
I've downloaded the update site and given it a whirl.
The problem I'm facing is all tests fail with NoClassDefFoundError(s) during the
run when
triggered from Run Crap4J, which doesn't occur if I Run As JUnit Test.
It still reports a CRAP result, etc, which is interesting.
Any ideas?
Cheers.
Greg
[Non-text portions of this message have been removed]
Send Email
