Re: [Gallery3] Unit test updates

--===============8581260890702715982==
Content-Type: multipart/alternative; boundary=001a11c339d2fedc2c04df9d3f63

--001a11c339d2fedc2c04df9d3f63
Content-Type: text/plain; charset=ISO-8859-1

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
>

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

<div dir=3D"ltr"><br><div style>I&#39;ve been wondering about that as well,=
 but I wasn&#39;t thinking about it from the unit test perspective. =A0I wa=
s thinking more along the lines of activating and deactivating modules duri=
ng a request&#39;s lifetime. =A0Eg, if we deactivate and reactivate a modul=
e several times, what is a developer supposed to do about their code in ini=
t.php? =A0Should devs guard against their code being called multiple times?=
 =A0It feels messy to me.</div>

<div style><br></div><div style>I think a better approach would be to minim=
ize what goes into init.php, preferably down to zero. =A0We can leave the f=
acility around, but since we&#39;re only using it for routes I think we cou=
ld easily have an event hook which sets routes, then we can call that from =
Module whenever we add a module.</div>

<div style><br></div><div style>If we want to be smart about removing route=
s 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 rem=
ove them when the module goes away, similar to how we do=A0Graphics::deacti=
vate_rules and=A0BlockManager::deactivate_blocks...</div>

<div style><br></div><div style><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 L=
aws <span dir=3D"ltr">&lt;<a href=3D"mailto:shad-xpYdmXCiSuZWk0Htik3J/[email protected]" target=3D"_b=
lank">shad-xpYdmXCiSuZWk0Htik3J/[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">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>

--001a11c339d2fedc2c04df9d3f63--


--===============8581260890702715982==
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
--===============8581260890702715982==
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 ]
--===============8581260890702715982==--