29 Jun
2009
29 Jun
'09
1:04 p.m.
On Jun 29, 2009, at 12:35 PM, Asiri Rathnayake wrote:
Hi,
On Mon, Jun 29, 2009 at 3:52 PM, Vincent Massol <vincent(a)massol.net>
wrote:
What you need is a class for storing images. A default implementation
would store in a temporary location on the file system. Another
implementation could store in memory or in a DB or...
You'd then use a dynamic mock implementation for the test which does
nothing.
-Vincent
On Jun 29, 2009, at 12:05 PM, Asiri Rathnayake wrote:
It's not the ChartGenerator that generates the chart image file.
ChartGenerator returns a byte[] which represents the chart. It's the
ChartMacro which writes out the chart image file.
I can avoid this problem by:
1. Declaring the chart image file generation method (generateChart)
abstract
in ChartMacro
2. Extending the ChartMacro with TestChartMacro (already done)
3. Overriding the generateChart method in ChartMacro and avoiding
the chart
image file being written to disk.
This will work fine and no files will be written on disk. I refused
to do
this because we wil be marking generateChart() method as abstract
only to
make it easy for us to write test cases.
Hi,
This is bad. For several reasons:
1) This is a unit test and it doesn't need to prove that jfreechart
works
2) Any application that creates files a bit everywhere are very bad.
Even if you added a remove on shutdown hook it would still be bad
since if the application was killed there would be leftovers.
3) It's easy for a unit test to control what happens and use mocks
where need be. It also improves the code design in general.
May be override the tearDown() method and cleanup
the file? But I'm
> not sure
> if this is possible with the way rendering tests are done.
No, no.
There are 2 options:
- Best: Do not create an image. Just verify that jfreechart is
called
and verify where it would create the image . To be done with some
mocks.
- Not as good: pass the location from the pom.xml. Actually it's
already passed by surefire so you just need to retrieve it as a
system
property.
Fixed by using "java.io.tmpdir" system property.