[rfc] Moving Robocop tests to mobile/android/tests

Chris Kitching chriskitching at linux.com
Thu Feb 13 13:12:33 PST 2014


Wouldn't that change make it much easier to finally kill off the 
annoying @RobocopTarget annotations I sprinkled through the codebase?
See, if Proguard were run over both the Robocop and Fennec classes at 
once, it would be able to figure out the calls from one to the other by 
itself and automagically produce a consistent output - no need for 
annotations.
There'd be other things to think about before actually doing that - is 
it sensilble to optimise the tests? Would the increased freedom of being 
able to "just reference" anything from Fennec in robocop lead to so many 
entry points that Proguard ends up effectively doing nothing? (Fixed by 
rerunning Proguard on optimised builds omitting Robocop classes - but 
then, testing not quite the same thing you're deploying?)

But still. It'd be easier to do this possibly nifty thing which might be 
thought of as a good idea at some point. That's a plus.

On 13/02/14 20:29, Nick Alexander wrote:
> Hi everybody,
>
> We've kicked around moving the Robocop tests to mobile/android/tests, 
> and Bug 938994 [1] tracks doing that.  One reason to incur this churn 
> is to make building Fennec and all the tests more straightforward.  
> Another reason is that this simplifies the build system a little.
>
> My vision for this is that we eventually make |mach build 
> mobile/android| the regular build step, and this builds updated tests.
>
> This is in contrast to the current state of affairs, where the regular 
> build step is |mach build mobile/android/base|, which doesn't build 
> tests, followed (hopefully) by |mach build build/mobile/robocop|.  
> Ugh.  Also, dependencies across these branches are pretty hairy.
>
> I have patches that move Robocop to 
> mobile/android/tests/browser/robocop at [1], with a green try build, 
> but it's going to bitrot *extremely* quickly.  It's only barely 
> reviewable, but I've asked glandium to look at the build system 
> parts.  If this is something we as a team are positive-to-neutral 
> about, I'd like to land this with cursory review and follow-up to 
> address issues.
>
> Opinions?
> Nick
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=938994
> _______________________________________________
> mobile-firefox-dev mailing list
> mobile-firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/mobile-firefox-dev



More information about the mobile-firefox-dev mailing list