11:32 a.m.
Hi,
Over the last few days I have been having a look at o.j.c.l.JDBCCacheLoaderPerfTest and I
have come to the conclusion that it needs changing.
Currently there're 3 tests, testPut(), testGet() and testRemove(). I tried running it
and I realised that testPut() would do its job but the other two would never find anything
in the database.
This could be controlled via setting drop table to false, but this would still not work as
cache.remove("/") is called on teardown().
These three tests are quite linked to each other as you expect puts to go first, then gets
and lastly removes. When running unit tests, you're not guaranteed order and taking in
account the relationship between the tests, I think the code inside these tests should be
joined into just one test.
Of couse, you'd need to evict the cache in between puts/gets and gets/removes so that
you can actually exercise the code fully right up to the cache loader.
Any thoughts?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/promo/vendor/
12:25 p.m.
On 6 Dec 2006, at 10:32, Galder Zamarreno wrote:
Hi,
Over the last few days I have been having a look at
o.j.c.l.JDBCCacheLoaderPerfTest and I have come to the conclusion
that it needs changing.
Currently there're 3 tests, testPut(), testGet() and testRemove().
I tried running it and I realised that testPut() would do its job
but the other two would never find anything in the database.
This could be controlled via setting drop table to false, but this
would still not work as cache.remove("/") is called on teardown().
These three tests are quite linked to each other as you expect puts
to go first, then gets and lastly removes. When running unit tests,
you're not guaranteed order and taking in account the relationship
between the tests, I think the code inside these tests should be
joined into just one test.
Of couse, you'd need to evict the cache in between puts/gets and
gets/removes so that you can actually exercise the code fully right
up to the cache loader.
Any thoughts?
Yes, something moving to TestNG would help with someday - finer
grained control over test setup and teardown structures as well as
the relationships between tests.
Keep in mind though, the purpose of this test is not like other unit,
stress or perf tests. It does not exercise functionality nor look
for bugs/leaks over time, nor measure any meaningful benchmarks. It
is simply an exercise to micro-bench individual operations so that,
while tuning the cacheloader code, you can measure the effect of your
enhancements. So this really should be treated more as a tuning tool
than anything else (and probably should be excluded from the cruise
control test suite as it is meaningless when run in CC)
And treating it as such a tool, the put, get and remove test methods
should be treated separately IMO. Moving them into a single method
may make profiling a bit hard. I see your point about setting up the
cache with proper data for get and remove tests though; perhaps
include a put loop at the start of get and remove to init the cache
first?
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
IT executives: Red Hat still #1 for value http://www.redhat.com/
promo/vendor/
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
6344
days inactive
6344
days old
jbosscache-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Galder Zamarreno -
Manik Surtani