Re: [SQLDroid] Add test suite (#5)
15 views
Skip to first unread message
Jim Redman
Oct 26, 2012, 10:09:02 AM10/26/12
to SQLDroid/SQLDroid, Uwe Kubosch, SQLDroid/SQLDroid, sqld...@googlegroups.com
Uwe,
Test suites are always a great thing. I think I created a test case for
each of the changes that I made - certainly the major ones. I have made
no real attempt build tests for the existing code, so the coverage is
not good. Without tests for existing functionality the tests won't
catch regressions.
Good test cases, without an issue to address, are difficult to write.
You can cover the base cases, but the corner cases escape you, and
that's always where the bugs are.
We should be able to run the tests on Android and on J2SE. There is
support for JUnit on Android. So long as we don't lose even the minimal
tests that we have, I don't much care. If there's a way to use Ruboto
on Android and Ruby on a PC against the same codebase, that's fine with me.
I think that test cases are an ongoing effort , retrofitting with 100%
coverage might be quite a project. Shooting for more test cases by
1.0.0 is good, 100% and we'll probably never release.
A good place to start would be a test case that covers the regression.
Jim
PS Is anyone on any of the SQLite mailing lists? It might be good to
announce the SQLDroid project there. Tests or no tests, I think
SQLDroid is more reliable and feature complete than other J2SE SQLite
JDBC drivers (totally unbiased opinion!).
On 10/26/2012 07:21 AM, Uwe Kubosch wrote:
> Before releasing the 1.0.0 version, I think we should have a working
> test suite.
>
> I experienced a regression between version 0.3.0 and 1.0.0.RC1, and we
> really should avoid that.
>
> I can add a test suite using Ruboto. I am on the Ruboto team, and that
> is how I use SQLDroid, so that is the natural way for me to test it.
> Does anybody else want to add a test suite in another way? Please speak
> up! I will back up any effort on this.
>
> If we decide that adding a test suite using Ruboto is OK, I would like
> some input on how to organise the test project. The easiest way for me
> is to convert the project to a Ruboto project. That will pollute the
> project a little, but makes testing very easy. I will push a proposal on
> how to do this on a "ruboto" branch so you can see how I imagine we can
> do it. Again, I welcome input on other ways to do it, for example as a
> separate test project independent of the core project.
>
> When a test suite is in place, we will run it on a continuos integration
> server on every commit to avoid regressions.
>
> What do you think?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/SQLDroid/SQLDroid/issues/5>.
>
--
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com
Test suites are always a great thing. I think I created a test case for
each of the changes that I made - certainly the major ones. I have made
no real attempt build tests for the existing code, so the coverage is
not good. Without tests for existing functionality the tests won't
catch regressions.
Good test cases, without an issue to address, are difficult to write.
You can cover the base cases, but the corner cases escape you, and
that's always where the bugs are.
We should be able to run the tests on Android and on J2SE. There is
support for JUnit on Android. So long as we don't lose even the minimal
tests that we have, I don't much care. If there's a way to use Ruboto
on Android and Ruby on a PC against the same codebase, that's fine with me.
I think that test cases are an ongoing effort , retrofitting with 100%
coverage might be quite a project. Shooting for more test cases by
1.0.0 is good, 100% and we'll probably never release.
A good place to start would be a test case that covers the regression.
Jim
PS Is anyone on any of the SQLite mailing lists? It might be good to
announce the SQLDroid project there. Tests or no tests, I think
SQLDroid is more reliable and feature complete than other J2SE SQLite
JDBC drivers (totally unbiased opinion!).
On 10/26/2012 07:21 AM, Uwe Kubosch wrote:
> Before releasing the 1.0.0 version, I think we should have a working
> test suite.
>
> I experienced a regression between version 0.3.0 and 1.0.0.RC1, and we
> really should avoid that.
>
> I can add a test suite using Ruboto. I am on the Ruboto team, and that
> is how I use SQLDroid, so that is the natural way for me to test it.
> Does anybody else want to add a test suite in another way? Please speak
> up! I will back up any effort on this.
>
> If we decide that adding a test suite using Ruboto is OK, I would like
> some input on how to organise the test project. The easiest way for me
> is to convert the project to a Ruboto project. That will pollute the
> project a little, but makes testing very easy. I will push a proposal on
> how to do this on a "ruboto" branch so you can see how I imagine we can
> do it. Again, I welcome input on other ways to do it, for example as a
> separate test project independent of the core project.
>
> When a test suite is in place, we will run it on a continuos integration
> server on every commit to avoid regressions.
>
> What do you think?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/SQLDroid/SQLDroid/issues/5>.
>
--
Jim Redman
(505) 662 5156 x85
http://www.ergotech.com
Jim Redman
Oct 26, 2012, 11:40:34 AM10/26/12
to SQLDroid/SQLDroid, Uwe Kubosch, SQLDroid/SQLDroid, sqld...@googlegroups.com
Uwe,
I'm also intrigued to know what the bug is.
Jim
On 10/26/2012 07:21 AM, Uwe Kubosch wrote:
> @dperiwal <https://github.com/dperiwal> @ergouser
> <https://github.com/ergouser> @kristianlm
> <https://github.com/kristianlm> @SQLDroid <https://github.com/SQLDroid>
> @SQLDroid/developers
>
> Addressing each of you in case you are not watching the repository :)
I'm also intrigued to know what the bug is.
Jim
On 10/26/2012 07:21 AM, Uwe Kubosch wrote:
> <https://github.com/ergouser> @kristianlm
> <https://github.com/kristianlm> @SQLDroid <https://github.com/SQLDroid>
> @SQLDroid/developers
>
> Addressing each of you in case you are not watching the repository :)
Uwe Kubosch
Oct 27, 2012, 5:55:34 AM10/27/12
to <sqldroid@googlegroups.com>, SQLDroid/SQLDroid, Uwe Kubosch, SQLDroid/SQLDroid
On 2012-10-26, at 17:40, Jim Redman <jre...@ergotech.com>
wrote:
> Uwe,
>
> I'm also intrigued to know what the bug is.
>
> Jim
The bug occurs high up in the ORM code, so it will take some time to analyse it. I'll keep you posted.
--
Uwe Kubosch
Systems Developer
Datek Wireless AS
u...@datek.no
http://datek.no/
wrote:
> Uwe,
>
> I'm also intrigued to know what the bug is.
>
> Jim
--
Uwe Kubosch
Systems Developer
Datek Wireless AS
u...@datek.no
http://datek.no/
Jim Redman
Oct 27, 2012, 10:15:17 AM10/27/12
to sqld...@googlegroups.com
Uwe,
One change that might affect that is the "changedRowCount" code so that
"execute" now (should) actually have the correct count of rows
inserted/change/etc.
Almost all the changes are counting related mostly relating to this
requirement from the statement javadocs:
/** There are no more results when the following is true:
// stmt is a Statement object
((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))*/
You'd think that would be easy, but, after a number of iterations, I'm
still not sure I have the best solution.
Jim
One change that might affect that is the "changedRowCount" code so that
"execute" now (should) actually have the correct count of rows
inserted/change/etc.
Almost all the changes are counting related mostly relating to this
requirement from the statement javadocs:
/** There are no more results when the following is true:
// stmt is a Statement object
((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))*/
You'd think that would be easy, but, after a number of iterations, I'm
still not sure I have the best solution.
Jim
Uwe Kubosch
Oct 27, 2012, 10:23:42 AM10/27/12
to <sqldroid@googlegroups.com>
On 2012-10-27, at 16:15, Jim Redman <jre...@ergotech.com> wrote:
> One change that might affect that is the "changedRowCount" code so that "execute" now (should) actually have the correct count of rows inserted/change/etc.
>
> Almost all the changes are counting related mostly relating to this requirement from the statement javadocs:
>
> /** There are no more results when the following is true:
> // stmt is a Statement object
> ((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))*/
>
> You'd think that would be easy, but, after a number of iterations, I'm still not sure I have the best solution.
This sounds related to the bug. I am getting the number -1 instead of a result set/array somewhere.
> One change that might affect that is the "changedRowCount" code so that "execute" now (should) actually have the correct count of rows inserted/change/etc.
>
> Almost all the changes are counting related mostly relating to this requirement from the statement javadocs:
>
> /** There are no more results when the following is true:
> // stmt is a Statement object
> ((stmt.getMoreResults() == false) && (stmt.getUpdateCount() == -1))*/
>
> You'd think that would be easy, but, after a number of iterations, I'm still not sure I have the best solution.
Jim Redman
Oct 27, 2012, 10:56:43 AM10/27/12
to sqld...@googlegroups.com
Sounds as though you might be calling "getUpdateCount()" more than once
on a result. The docs prohibit this:
"This method should be called only once per result."
from:
http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()
Jim
On 10/27/2012 08:23 AM, Uwe Kubosch wrote:
> On 2012-10-27, at 16:15, Jim Redman<jre...@ergotech.com> wrote:
>
>> One change that might affect that is the "changedRowCount" code so that "execute" now (should) actually have the correct count of rows inserted/change/etc.
>>
>> Almost all the changes are counting related mostly relating to this requirement from the statement javadocs:
>>
>> /** There are no more results when the following is true:
>> // stmt is a Statement object
>> ((stmt.getMoreResults() == false)&& (stmt.getUpdateCount() == -1))*/
on a result. The docs prohibit this:
"This method should be called only once per result."
from:
http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()
Jim
On 10/27/2012 08:23 AM, Uwe Kubosch wrote:
> On 2012-10-27, at 16:15, Jim Redman<jre...@ergotech.com> wrote:
>
>> One change that might affect that is the "changedRowCount" code so that "execute" now (should) actually have the correct count of rows inserted/change/etc.
>>
>> Almost all the changes are counting related mostly relating to this requirement from the statement javadocs:
>>
>> /** There are no more results when the following is true:
>> // stmt is a Statement object
>>
>> You'd think that would be easy, but, after a number of iterations, I'm still not sure I have the best solution.
>
> This sounds related to the bug. I am getting the number -1 instead of a result set/array somewhere.
>
> --
> Uwe Kubosch
> Systems Developer
> Datek Wireless AS
> u...@datek.no
> http://datek.no/
>
>> You'd think that would be easy, but, after a number of iterations, I'm still not sure I have the best solution.
>
> This sounds related to the bug. I am getting the number -1 instead of a result set/array somewhere.
>
> --
> Uwe Kubosch
> Systems Developer
> Datek Wireless AS
> u...@datek.no
> http://datek.no/
>
Uwe Kubosch
Oct 28, 2012, 12:14:21 PM10/28/12
to <sqldroid@googlegroups.com>
Still working on tracking down the bug. My app was missing a proper test suite for this, so I am building that. Will take some more time.
On 2012-10-27, at 16:56, Jim Redman <jre...@ergotech.com> wrote:
> Sounds as though you might be calling "getUpdateCount()" more than once on a result. The docs prohibit this:
>
> "This method should be called only once per result."
>
> from:
>
> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()
>
> Jim
On 2012-10-27, at 16:56, Jim Redman <jre...@ergotech.com> wrote:
> Sounds as though you might be calling "getUpdateCount()" more than once on a result. The docs prohibit this:
>
> "This method should be called only once per result."
>
> from:
>
> http://docs.oracle.com/javase/6/docs/api/java/sql/Statement.html#getUpdateCount()
>
> Jim
Reply all
Reply to author
Forward
0 new messages