No subject

Sun Mar 31 09:34:23 UTC 2013

as fast as it could be due to using sqlite as well.
I distinctly remember making the postgres tests start up faster but not
being able to due to the complication of having to support sqlite as well.

> But just in case that takes another 3 years before that is complete,
> may I suggest keeping sqlite in the meantime? ;-)
>
> Interesting idea about 'defaulting' developers to using a test mode
> that uses sqlite for some tests and postgres for others. Sounds like a
> can of worms though, judging by the existing debate on sqlite.
>
> David
>
>
> On 14 June 2013 15:15, Sean Hammond <sean.hammond at okfn.org> wrote:
> >> > Right, I'll often run the specific test modules that the code I'm
> >> working on affects frequently as I'm developing, but only run the whole
> >> test suite at the end before merging to master (if at all, Travis will
> >> often have run it for me).
> >>
> >> Great, you're finally addressing the situation that I'm talking about
> >> (I'm in agreement about not running the full tests - leave it to
> >> Travis).
> >>
> >> As per my example, postgres takes 12s versus sqlite 3s for running a
> >> couple of simple tests - the ones relevant to the code currently being
> >> written. As you add a couple of lines of code and add a new assert to
> >> the test in parallel with the feature, you'll find yourself running
> >> the relevant tests several times a minute. Waiting 12s for them to run
> >> each time and you simply break your flow.
> >
> > I'm not convinced about this. You're telling me that the unit tests for
> > one module takes 12s to run with postgres and 3s with sqlite? And this
> > isn't because either the tests or the ckan module is badly designed?
> >
> > Anyway, from my point of view, there should only be one way of running
> > the tests and it should be fast. As discussed introducing "run the tests
> > with postgres" and "run the same tests, but with sqlite" creates various
> > problems. I think the right way to do this might be to write more
> > testable code that's easier and faster to test in the first place, and
> > then write better and faster tests for it.
> >
> > For example, rather than either running all the tests with postgres and
> > then having a different command to run all the tests with sqlite
> > instead, a particular CKAN module that uses the database should accept a
> > database object as parameter, in normal operation it would be passed a
> > postgres database object but the tests could pass it an in-memory sqlite
> > database object instead.
> >
> > If we used this approach throughout then you would have just one command
> > "run the tests" and each test would use either a postgres database
> > (when really necessary) or a faster sqlite one whenever possible.
> > Hopefully the tests overall would be pretty fast, and running the tests
> > for most individual modules would be very fast and not touch the disk at
> > all. And no problem with having two separate ways of running the tests.
> >
> > _______________________________________________
> > ckan-dev mailing list
> > ckan-dev at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/ckan-dev
> > Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>

--089e01538800685a8304df23e80f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Jun 14, 2013 at 3:59 PM, David Read <span dir=3D"ltr">&lt;<=
a href=3D"mailto:david.read at hackneyworkshop.com" target=3D"_blank">david.re=
ad at hackneyworkshop.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The time taken on postgres is nothing to do =
with CKAN core or the 
specific tests. It is a result of postgres dropping dozens of tables 
and recreating them. I think when David did the current postgres test 
setup it was in haste and it is clear to anyone reading logging during 
tests that it could be improved somewhat. So please do improve it! :-) <=
/blockquote><div> I also did the current sqlite test setup if that is th=
e case and there was a lot of pain in doing it and is why I still want it r=
emoved.

=A0<br></div><div>From what I remember there where compromises in making th=
e postgres setup as fast as it could be due to using sqlite as well.=A0 <br=
>I distinctly remember making the postgres tests start up faster but not be=
ing able to due to the complication of having to support sqlite as well.<br=
>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
 
But just in case that takes another 3 years before that is complete, 
may I suggest keeping sqlite in the meantime? ;-) 
 
Interesting idea about &#39;defaulting&#39; developers to using a test mode=
 
that uses sqlite for some tests and postgres for others. Sounds like a 
can of worms though, judging by the existing debate on sqlite. 
 
David 
<div class=3D"HOEnZb"><div class=3D"h5"> 
 
On 14 June 2013 15:15, Sean Hammond &lt;<a href=3D"mailto:sean.hammond at okfn=
.org">sean.hammond at okfn.org</a>&gt; wrote: 
&gt;&gt; &gt; Right, I&#39;ll often run the specific test modules that the =
code I&#39;m 
&gt;&gt; working on affects frequently as I&#39;m developing, but only run =
the whole 
&gt;&gt; test suite at the end before merging to master (if at all, Travis =
will 
&gt;&gt; often have run it for me). 
&gt;&gt; 
&gt;&gt; Great, you&#39;re finally addressing the situation that I&#39;m ta=
lking about 
&gt;&gt; (I&#39;m in agreement about not running the full tests - leave it =
to 
&gt;&gt; Travis). 
&gt;&gt; 
&gt;&gt; As per my example, postgres takes 12s versus sqlite 3s for running=
 a 
&gt;&gt; couple of simple tests - the ones relevant to the code currently b=
eing 
&gt;&gt; written. As you add a couple of lines of code and add a new assert=
 to 
&gt;&gt; the test in parallel with the feature, you&#39;ll find yourself ru=
nning 
&gt;&gt; the relevant tests several times a minute. Waiting 12s for them to=
 run 
&gt;&gt; each time and you simply break your flow. 
&gt; 
&gt; I&#39;m not convinced about this. You&#39;re telling me that the unit =
tests for 
&gt; one module takes 12s to run with postgres and 3s with sqlite? And this=
 
&gt; isn&#39;t because either the tests or the ckan module is badly designe=
d? 
&gt; 
&gt; Anyway, from my point of view, there should only be one way of running=
 
&gt; the tests and it should be fast. As discussed introducing &quot;run th=
e tests 
&gt; with postgres&quot; and &quot;run the same tests, but with sqlite&quot=
; creates various 
&gt; problems. I think the right way to do this might be to write more 
&gt; testable code that&#39;s easier and faster to test in the first place,=
 and 
&gt; then write better and faster tests for it. 
&gt; 
&gt; For example, rather than either running all the tests with postgres an=
d 
&gt; then having a different command to run all the tests with sqlite 
&gt; instead, a particular CKAN module that uses the database should accept=
 a 
&gt; database object as parameter, in normal operation it would be passed a=
 
&gt; postgres database object but the tests could pass it an in-memory sqli=
te 
&gt; database object instead. 
&gt; 
&gt; If we used this approach throughout then you would have just one comma=
nd 
&gt; &quot;run the tests&quot; and each test would use either a postgres da=
tabase 
&gt; (when really necessary) or a faster sqlite one whenever possible. 
&gt; Hopefully the tests overall would be pretty fast, and running the test=
s 
&gt; for most individual modules would be very fast and not touch the disk =
at 
&gt; all. And no problem with having two separate ways of running the tests=
. 
&gt; 
&gt; _______________________________________________ 
&gt; ckan-dev mailing list 
&gt; <a href=3D"mailto:ckan-dev at lists.okfn.org">ckan-dev at lists.okfn.org</a>=
 
&gt; <a href=3D"http://lists.okfn.org/mailman/listinfo/ckan-dev" target=3D"=
_blank">http://lists.okfn.org/mailman/listinfo/ckan-dev</a> 
&gt; Unsubscribe: <a href=3D"http://lists.okfn.org/mailman/options/ckan-dev=
" target=3D"_blank">http://lists.okfn.org/mailman/options/ckan-dev</a> 
 
_______________________________________________ 
ckan-dev mailing list 
<a href=3D"mailto:ckan-dev at lists.okfn.org">ckan-dev at lists.okfn.org</a> 
<a href=3D"http://lists.okfn.org/mailman/listinfo/ckan-dev" target=3D"_blan=
k">http://lists.okfn.org/mailman/listinfo/ckan-dev</a> 
Unsubscribe: <a href=3D"http://lists.okfn.org/mailman/options/ckan-dev" tar=
get=3D"_blank">http://lists.okfn.org/mailman/options/ckan-dev</a> 
</div></div></blockquote></div> </div></div>

--089e01538800685a8304df23e80f--