Re: [Gallery3] Unit test updates

Bharat Mediratta <[email protected]> Thu, 20 Jun 2013 16:12:31 -0700
Newsgroups gmane.comp.web.gallery.devel
Message-ID <CAESa+_kbwUwfsGL+b1KCR4c=U-yTXBxD8u1tgZa7sR=07gMGOw@mail.gmail.com>
--===============2575325171677386155==
Content-Type: multipart/alternative; boundary=089e015387dc12ee7104df9e1753

--089e015387dc12ee7104df9e1753
Content-Type: text/plain; charset=ISO-8859-1

I think that's reasonable.  I've never been 100% happy with putting the
"ready" event in Controller::execute.


On Thu, Jun 20, 2013 at 3:44 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> I like the idea of reducing the init.php's down to zero and putting it in
> an event, and agree that trying to keep track of this isn't a good idea.
>  In fact, we could probably just move the execution of the already-existing
> "ready" event from Controller::execute() to either bootstrap.php or
> index.php (just before the initial request generation).  I wonder - should
> it be renamed "init" to make its analog more obvious?
>
> Then, we just add a Route override that clears out the Route list, and use
> it in Module to activate/deactivate things as well as in the unit test.
>
> Thoughts?
>
> Take care,
> Shad
>
> On 21 June 2013 00:12, Bharat Mediratta <[email protected]> wrote:
>
>>
>> I've been wondering about that as well, but I wasn't thinking about it
>> from the unit test perspective.  I was thinking more along the lines of
>> activating and deactivating modules during a request's lifetime.  Eg, if we
>> deactivate and reactivate a module several times, what is a developer
>> supposed to do about their code in init.php?  Should devs guard against
>> their code being called multiple times?  It feels messy to me.
>>
>> I think a better approach would be to minimize what goes into init.php,
>> preferably down to zero.  We can leave the facility around, but since we're
>> only using it for routes I think we could easily have an event hook which
>> sets routes, then we can call that from Module whenever we add a module.
>>
>> If we want to be smart about removing routes when a module is deactivated
>> (not essential for us to do right now, IMO) we could always track which
>> routes were added when we call the hook and remove them when the module
>> goes away, similar to how we do Graphics::deactivate_rules
>> and BlockManager::deactivate_blocks...
>>
>>
>>
>>
>> On Thu, Jun 20, 2013 at 10:52 AM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>
>>> Hey Bharat,
>>>
>>> It looks like, except for the REST-related unit tests I'm still wrapping
>>> up, the only tests left are controller auth and XSS - woohoo!
>>>
>>> I did, however, hit a minor snag.  I got everything running well and
>>> passing, hit a reset button, and then everything broke with the REST tests
>>> - crap!  After a bit of digging, I found the problem: the REST tests won't
>>> pass on a fresh installation.  They only pass if you activate the rest
>>> module, *then* run unit tests.
>>>
>>> The issue is the rest module's init.php file.  Like the other init.php
>>> files (e.g. in tag), it's designed to run *before* the bootstrap routes are
>>> defined.  That way, they get precedence.  However, if you roll a fresh
>>> install (which has rest disabled) straight into a unit test, it bombs - the
>>> bootstrap runs first, then rest's init.php later... and it doesn't work :-/
>>>
>>> One thought I have is to override the Route class so we can clear them
>>> and restart from scratch, then make the unit tests re-load them all... but
>>> that sounds kinda hacky and flaky (e.g. what happens if an init.php does
>>> something besides load routes?).  Any better thoughts?
>>>
>>> Take care,
>>> Shad
>>>
>>
>>
>

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

<div dir=3D"ltr"><br><div style>I think that&#39;s reasonable. =A0I&#39;ve =
never been 100% happy with putting the &quot;ready&quot; event in Controlle=
r::execute.</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gma=
il_quote">

On Thu, Jun 20, 2013 at 3:44 PM, Shad Laws <span dir=3D"ltr">&lt;<a href=3D=
"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target=3D"_blank">shad-xpYdmXCiSuZWk0Htik3J/[email protected]</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">

I like the idea of reducing the init.php&#39;s down to zero and putting it =
in an event, and agree that trying to keep track of this isn&#39;t a good i=
dea. =A0In fact, we could probably just move the execution of the already-e=
xisting &quot;ready&quot; event from Controller::execute() to either bootst=
rap.php or index.php (just before the initial request generation). =A0I won=
der - should it be renamed &quot;init&quot; to make its analog more obvious=
?<div>



<br></div><div>Then, we just add a Route override that clears out the Route=
 list, and use it in Module to activate/deactivate things as well as in the=
 unit test.</div><div><br></div><div>Thoughts?</div><div><br></div><div>



Take care,</div><div>Shad</div><div class=3D"HOEnZb"><div class=3D"h5"><div=
><div><div><br><div class=3D"gmail_quote">On 21 June 2013 00:12, Bharat Med=
iratta <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank">[email protected]</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"><div dir=3D"ltr"><br><div>I&#39;ve been wond=
ering about that as well, but I wasn&#39;t thinking about it from the unit =
test perspective. =A0I was thinking more along the lines of activating and =
deactivating modules during a request&#39;s lifetime. =A0Eg, if we deactiva=
te and reactivate a module several times, what is a developer supposed to d=
o about their code in init.php? =A0Should devs guard against their code bei=
ng called multiple times? =A0It feels messy to me.</div>





<div><br></div><div>I think a better approach would be to minimize what goe=
s into init.php, preferably down to zero. =A0We can leave the facility arou=
nd, but since we&#39;re only using it for routes I think we could easily ha=
ve an event hook which sets routes, then we can call that from Module whene=
ver we add a module.</div>





<div><br></div><div>If we want to be smart about removing routes when a mod=
ule is deactivated (not essential for us to do right now, IMO) we could alw=
ays track which routes were added when we call the hook and remove them whe=
n the module goes away, similar to how we do=A0Graphics::deactivate_rules a=
nd=A0BlockManager::deactivate_blocks...</div>





<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Thu, Jun 20, 2013 at 10:52 AM, Shad Laws <span di=
r=3D"ltr">&lt;<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target=3D"_blank">shad@s=
hadlaws.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">Hey Bharat,<div><br></div><div>It looks like=
, except for the REST-related unit tests I&#39;m still wrapping up, the onl=
y tests left are controller auth and XSS - woohoo!</div>





<div><br></div><div>I did, however, hit a minor snag. =A0I got everything r=
unning well and passing, hit a reset button, and then everything broke with=
 the REST tests - crap! =A0After a bit of digging, I found the problem: the=
 REST tests won&#39;t pass on a fresh installation. =A0They only pass if yo=
u activate the rest module, *then* run unit tests.</div>







<div><br></div><div>The issue is the rest module&#39;s init.php file. =A0Li=
ke the other init.php files (e.g. in tag), it&#39;s designed to run *before=
* the bootstrap routes are defined. =A0That way, they get precedence. =A0Ho=
wever, if you roll a fresh install (which has rest disabled) straight into =
a unit test, it bombs - the bootstrap runs first, then rest&#39;s init.php =
later... and it doesn&#39;t work :-/</div>







<div><br></div><div>One thought I have is to override the Route class so we=
 can clear them and restart from scratch, then make the unit tests re-load =
them all... but that sounds kinda hacky and flaky (e.g. what happens if an =
init.php does something besides load routes?). =A0Any better thoughts?</div=
>







<div><br></div><div>Take care,</div><div>Shad</div>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div>
</div></div></blockquote></div><br></div>

--089e015387dc12ee7104df9e1753--


--===============2575325171677386155==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
--===============2575325171677386155==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]
--===============2575325171677386155==--