Closed GoogleCodeExporter closed 8 years ago
With r813 most JUnit tests run again. However, some (important) tests still
fail:
* SPARQLServletPojoTest
* HttpDeleteServiceOnTripleStoreTest
* RemoveTest
* QuadsTest
* QuadsDeletionTest
I will look into those the next days ...
- Andreas
Original comment by andreas.josef.wagner
on 3 Feb 2014 at 1:50
Wow, nice shot!
For HttpDeleteServiceOnTripleStoreTest, at least locally, tests are
green if you run them separately, so that should be something with setup
/ teardown methods.
Original comment by a.gazzarini@gmail.com
on 3 Feb 2014 at 5:55
Ok,
HttpDeleteServiceOnTripleStoreTest now is green...that was my stupid
mistake...testset iterator was static so once traversed in the first
test method its hasNext always returned false.
Now, I will split CRUDServletPojoTest in one test case for each REST
service (like HttpDeleteServiceOnTripleStoreTest is for DELETE)
Original comment by a.gazzarini@gmail.com
on 3 Feb 2014 at 8:30
I added a dedicated test case for POST REST service
(HttpPostServiceOnTripleStore).
- all (both positive and negative) tests are green.
- test coverage indicates that we should run tests with all supported
formats but since there's a todo (in CRUDServlet.doPost) for supporting
as much formats as possible I think we take care about that later (I
will open a separate issue / enhancement)
Original comment by a.gazzarini@gmail.com
on 3 Feb 2014 at 10:39
Added a dedicated test case for GET REST service
(HttpGetServiceOnTripleStore).
- all (both positive and negative) tests are green.
- test coverage indicates that there are some branches not covered
(mainly one branch for supported format)
- CRUDServletPojoiTest has been commented out because incompatible
changes. When the last test (PUT) will be created it could be removed.
Original comment by a.gazzarini@gmail.com
on 3 Feb 2014 at 10:52
Added a dedicated test case for PUT REST service
(HttpPutServiceOnTripleStore) with r861
Original comment by a.gazzarini@gmail.com
on 6 Feb 2014 at 6:59
Fixed with r892 : we have 148 green tests
Original comment by a.gazzarini@gmail.com
on 14 Feb 2014 at 4:07
Very cool :) Thanks for your good work. However, it seems we still have some
Exceptions in the test runs. For some reason, we don't see this in the test
outcomes?! I don't know why ...
Attached find the console output from the build#5 ... The exceptions don't seem
to major problems - some NullPointers, ParserExceptions etc. But we still
should fix them.
Kind regards
Andreas
Original comment by andreas.josef.wagner
on 16 Feb 2014 at 1:23
Attachments:
This is also a strange ERROR in the above log (not an Execption, though):
ERROR [edu.kit.aifb.cumulus.util.hector.CassandraHectorCounterFactory] counter:
TRIPLE_COUNTER suffered an overflow! current counter value: -3
This should not happen in the tests ;)
Original comment by andreas.josef.wagner
on 16 Feb 2014 at 1:26
... reopening the issue ...
- Andreas
Original comment by andreas.josef.wagner
on 16 Feb 2014 at 1:28
Hi Andreas,
NPEs are ok, those test cases want that specific behaviour :D You can see in
GET / POST / PUT (CRUDServlet) tests...for each of them there are two test
cases that
- try to see what happens in case of CumulusException: as commented there I'm
not emulating each scenario that could raise that problem...just injecting a
Store in ServletContext that is not yet open. The exception is caught, prnted
out and the server sends a 500 INTERNAL SERVER ERROR as expected. You are
seeing the exception because the logger on the servlet.
- try to see what happens in case of *Exception: the catch (Exception) is the
last block of each get/put/post method so here the test is seeing that if a
(example) RuntimeException is thrown, the the expected result must be a 500
INTERNAL SERVER ERROR. You are seeing the exception because the logger on the
servlet.
I'm going to see the other exception you mentioned.
Original comment by a.gazzarini@gmail.com
on 16 Feb 2014 at 2:02
After checking, all exceptions that are printed out during the execution of
tests are expected, so I'm closing this issue.
Original comment by a.gazzarini@gmail.com
on 1 Mar 2014 at 9:50
Original issue reported on code.google.com by
a.gazzarini@gmail.com
on 31 Jan 2014 at 2:21