date:20121025

Proposal for reorganizing test directories

2012-10-25 Thread Henrik Skupin

Hi all,

When I started to work on tests for WebRTC and WebAPI lately I have
noticed that there are no clear specifications where tests have to be
added. Some are located in a tests subdirectory (like
/dom/feature/tests/) while others are under a testing folder (like
/dom/testing/mochitest). This is totally confusing and as an internal
discussion in the automation and tools team has been shown, we would
support a location of tests which are under the feature which means
directly beneath the actual source.

The proposal would be the following hierarchy:

|-- feature/
|-- tests/
|-- browser-chrome/
|-- chrome/
|-- crashtests/
|-- marionette/
|-- mochitests/
|-- reftests/
|-- xpcshell
|-- [..]/

So tests for each type of test framework will get their own subfolder
under tests. That will make it easier for everyone to get started and we
can retain a clear structure of our tests.

With this post we want to get feedback from module owners and how they
feel with such a reorganization of the tests. If we agree all on it I
would like to go ahead and submit patches in smaller chunks most likely
on a per module basis. I know that will be a lot of work, so I will do
it beside my actual work and try to get as many contributors as possible
to helping out via mentored bugs.

Once agreed on our team will also add proper documentation on MDN as
part of our
current documentation revamp project for test frameworks.

Thanks a lot,

-- 
Henrik Skupin
Software Engineer in Test
Mozilla Corporation

-- 
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for reorganizing test directories

2012-10-25 Thread Henrik Skupin

Justin Lebar wrote on 10/25/12 10:06 AM:

 I'd probably be a lot more sympathetic to this proposal if I
 understood in a concrete way how making my life a little harder here
 would make your life a little easier.  What problem exactly are you
 trying to solve?

Good points. So let me give one example.

I was looking at the following URL:
http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/

Why have those tests be placed into this location and not beside the
actual implementation code? It's hard when you work on tests (e.g.
fixing brokenness) and you have to check the implementation. It takes a
bit of time you have to spend on figuring out where the source actually
lives.

 I personally like the fact that we don't have the tests in
 dom/browser-element/tests/mochitest.  The extra directory would have
 just one child, so from my perspective, it would add very little.  (I
 have to type this path all the time.)  I don't know how many other
 folders you'd need to change in a similar way.

I don't think I have a problem with it. If there is only one single type
of test harness used,  we could have the tests directly under a folder
with it's name. Once more are getting added we could consider to move
e.g. the mochitests to tests/mochitest/.

-- 
Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for reorganizing test directories

2012-10-25 Thread Boris Zbarsky


On 10/25/12 11:51 AM, Rob Campbell wrote:

You won't have browser-chrome living next to xpcshell in the same location 
(pretty sure, please correct me if I'm wrong).


http://mxr.mozilla.org/mozilla-central/source/docshell/test/

It's got xpcshell tests, xpcshell-ipc tests, browser tests, 
browser-chrome tests, mochitests.  No reftests yet, but a bunch of the 
chrome tests and mochitests here do similar things using WindowSnapshot.


This is not as isolated example as you might think. 
http://mxr.mozilla.org/mozilla-central/source/content/base/test/ has 
similar things going on, for example, and I'm sure I could find more.


Granted, if we more finely subdivide our directory structure we would 
have fewer directories with a variety of test types.  But it's not clear 
to me how beneficial such subdivision of source files is.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for reorganizing test directories

2012-10-25 Thread Justin Lebar

Ah, interesting.  I think I misunderstood the main point of your
proposal -- your purpose isn't to standardize the names of directories
which contain tests much as to move tests closer in the directory
structure to the code they're testing.

Thanks for clarifying.

 So let me give one example.

 I was looking at the following URL:
 http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/

 Why have those tests be placed into this location and not beside the
 actual implementation code? It's hard when you work on tests (e.g.
 fixing brokenness) and you have to check the implementation. It takes a
 bit of time you have to spend on figuring out where the source actually
 lives.

I don't think this is as simple as you make it out to be.  Even
supposing we can identify a single directory which most of the code
that a test is testing lives in and that we move the test there, when
you look at a test and try to find the code it's testing, you still
have to identify where in that directory the code under test actually
lives, and that's non-trivial.

I'd contend that in both the current and proposed schemes, the fastest
way to find the code that's being tested is the same: Look at the bug
number in the test name (or hg log to find it, if the test name
doesn't have a bug number).  Open that bug in bugzilla and you'll
probably quickly find the code under test.

I'm sure there's room for improvement in how we organize our tests,
and if you think you have a better way of organizing specifically the
DOM tests, I'd love to see it.

But I'm not convinced that a full-on policy dictating that everyone
must organize their tests as you outlined would be beneficial.  I'd
rather that you convince module owners to follow your lead by virtue
of its being obviously better than the alternative.

On Thu, Oct 25, 2012 at 11:49 AM, Henrik Skupin hsku...@gmail.com wrote:
 Justin Lebar wrote on 10/25/12 10:06 AM:

 I'd probably be a lot more sympathetic to this proposal if I
 understood in a concrete way how making my life a little harder here
 would make your life a little easier.  What problem exactly are you
 trying to solve?

 Good points. So let me give one example.

 I was looking at the following URL:
 http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/

 Why have those tests be placed into this location and not beside the
 actual implementation code? It's hard when you work on tests (e.g.
 fixing brokenness) and you have to check the implementation. It takes a
 bit of time you have to spend on figuring out where the source actually
 lives.

 I personally like the fact that we don't have the tests in
 dom/browser-element/tests/mochitest.  The extra directory would have
 just one child, so from my perspective, it would add very little.  (I
 have to type this path all the time.)  I don't know how many other
 folders you'd need to change in a similar way.

 I don't think I have a problem with it. If there is only one single type
 of test harness used,  we could have the tests directly under a folder
 with it's name. Once more are getting added we could consider to move
 e.g. the mochitests to tests/mochitest/.

 --
 Henrik
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal for reorganizing test directories

2012-10-25 Thread Jason Duell

 Why have those tests be placed into this location and not beside the 
actual implementation code?


Necko has had a general policy of not allowing mochitests within the 
/netwerk tree, so any cookie, etc tests that need browser functionality 
(i.e. more than xpcshell) live elsewhere.  It's really mostly a nervous 
tic at this point, left over from when we had the priority of making our 
network libraries a browser-independent module that other projects could 
take up (few have, and we officially Don't Care® as of a few years ago).


Jason
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: deadlock while flash plugin calls posturlnotify

2012-10-25 Thread LANGLOIS Olivier PIS -EXT

I have found the problem!

when the main thread may wait on future events such as when it is notifying 
another thread to shutdown, the code in nsBaseAppShell::OnProcessNextEvent 
enters the glib loop assuming that native events will occur frequently allowing 
it exit eventually when the thread event q receive a new event. In some cases, 
(mine) no native events ever occur (it could be because no keyboard or mouse is 
connected).

  while (!NS_HasPendingEvents(thr)  !mProcessedGeckoEvents) {
// If we have been asked to exit from Run, then we should not wait for
// events to process.  Note that an inner nested event loop causes
// 'mayWait' to become false too, through 'mBlockedWait'.
if (mExiting)
  mayWait = false;

mLastNativeEventTime = PR_IntervalNow();
if (!DoProcessNextNativeEvent(mayWait, recursionDepth) || !mayWait)
  break;
  }

An easy way to fix it would be to do that:

DoProcessNextNativeEvent(false, recursionDepth);
if(!mayWait)
  break;

The best way IMO, would be to specify a small to value (ie 20ms) but it doesn't 
seems to be trivial to do with glib. (you have to add some kind of g_source to 
the default g_context) and this is beyond my field of expertise

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 8:59 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify

Karl,

Here is the call stack:

There must be a pollwrapper flipping the MayWait flag to infinite to. Hence on 
my VM, there is always some event but since on my real hardware I have no input 
devices, this makes events rarer...

Let me clear that last point before opening a new bug. I'll check if the guilty 
is not my old wxWidget library...

#0  0xb7fa8410 in __kernel_vsyscall ()
#1  0xb7218fbc in poll () from /lib/libc.so.6
#2  0xb7406f6d in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb7ab0917 in wxapp_poll_func () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#4  0xb587cf0a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3F0A 
(PollWrapper(_GPollFD*, unsigned int, int))
#5  0xb73fdc68 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb73fdebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#7  0xb587cc97 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3C97 
(nsAppShell::ProcessNextNativeEvent)
#8  0xb5895360 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC360 
(nsBaseAppShell::DoProcessNextNativeEvent)
#9  0xb589547a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC47A 
(nsBaseAppShell::OnProcessNextEvent)
#10 0xb5b4bdf0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2DF0 
(nsThread::ProcessNextEvent)
#11 0xb5afdae8 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 
(NS_ProcessNextEvent_P)
#12 0xb5b4b752 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2752 
(nsThread::Shutdown)
#13 0xb5b4d648 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B4648 
(nsRunnableMethodImplunsigned int (nsIThread::*)(), true::Run)
#14 0xb5b4bf72 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2F72 
(nsThread::ProcessNextEvent)
#15 0xb5afdbe0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01464BE0 
(NS_ProcessPendingEvents_P)
#16 0xb5894c13 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FBC13 
(nsBaseAppShell::NativeEventCallback)
#17 0xb587cfff in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3FFF 
(nsAppShell::EventProcessorCallback)
#18 0xb742ddd4 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0xb73fba29 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0xb73fdcc1 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0xb73fde4d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0xb6ebb7bd in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7acab05 in wxEventLoop::Run () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#24 0xb7b4ff6e in wxAppBase::MainLoop () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#25 0xb7b4fb41 in wxAppBase::OnRun () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#26 0x0808e161 in LayoutEngineClass::OnRun ()
#27 0xb7dc032a in wxEntry () from /opt/400T/ramdisk/lib/libwx_base-2.8.so.0
#28 0x0808e973 in main ()

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 7:18 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify


LANGLOIS Olivier writes:

 xulrunner: 16.0.1

Is this a regression?
i.e. Do you know whether it worked differently in previous versions?

Kindof but I'm coming from very far in the past. I'm

RE: deadlock while flash plugin calls posturlnotify

2012-10-25 Thread LANGLOIS Olivier PIS -EXT

https://bugzilla.mozilla.org/show_bug.cgi?id=805529

has been filed.

Thank you!
Olivier

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Thursday, October 25, 2012 2:04 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify

I have found the problem!

when the main thread may wait on future events such as when it is notifying 
another thread to shutdown, the code in nsBaseAppShell::OnProcessNextEvent 
enters the glib loop assuming that native events will occur frequently allowing 
it exit eventually when the thread event q receive a new event. In some cases, 
(mine) no native events ever occur (it could be because no keyboard or mouse is 
connected).

  while (!NS_HasPendingEvents(thr)  !mProcessedGeckoEvents) {
// If we have been asked to exit from Run, then we should not wait for
// events to process.  Note that an inner nested event loop causes
// 'mayWait' to become false too, through 'mBlockedWait'.
if (mExiting)
  mayWait = false;

mLastNativeEventTime = PR_IntervalNow();
if (!DoProcessNextNativeEvent(mayWait, recursionDepth) || !mayWait)
  break;
  }

An easy way to fix it would be to do that:

DoProcessNextNativeEvent(false, recursionDepth);
if(!mayWait)
  break;

The best way IMO, would be to specify a small to value (ie 20ms) but it doesn't 
seems to be trivial to do with glib. (you have to add some kind of g_source to 
the default g_context) and this is beyond my field of expertise

-Original Message-
From: 
dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org
 
[mailto:dev-platform-bounces+olivier.pis.langlois=transport.alstom@lists.mozilla.org]
 On Behalf Of LANGLOIS Olivier PIS -EXT
Sent: Wednesday, October 24, 2012 8:59 PM
To: Karl Tomlinson; dev-platform@lists.mozilla.org
Subject: RE: deadlock while flash plugin calls posturlnotify

Karl,

Here is the call stack:

There must be a pollwrapper flipping the MayWait flag to infinite to. Hence on 
my VM, there is always some event but since on my real hardware I have no input 
devices, this makes events rarer...

Let me clear that last point before opening a new bug. I'll check if the guilty 
is not my old wxWidget library...

#0  0xb7fa8410 in __kernel_vsyscall ()
#1  0xb7218fbc in poll () from /lib/libc.so.6
#2  0xb7406f6d in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb7ab0917 in wxapp_poll_func () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#4  0xb587cf0a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3F0A 
(PollWrapper(_GPollFD*, unsigned int, int))
#5  0xb73fdc68 in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb73fdebe in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#7  0xb587cc97 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3C97 
(nsAppShell::ProcessNextNativeEvent)
#8  0xb5895360 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC360 
(nsBaseAppShell::DoProcessNextNativeEvent)
#9  0xb589547a in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FC47A 
(nsBaseAppShell::OnProcessNextEvent)
#10 0xb5b4bdf0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2DF0 
(nsThread::ProcessNextEvent)
#11 0xb5afdae8 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 
(NS_ProcessNextEvent_P)
#12 0xb5b4b752 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2752 
(nsThread::Shutdown)
#13 0xb5b4d648 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B4648 
(nsRunnableMethodImplunsigned int (nsIThread::*)(), true::Run)
#14 0xb5b4bf72 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x014B2F72 
(nsThread::ProcessNextEvent)
#15 0xb5afdbe0 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x01464BE0 
(NS_ProcessPendingEvents_P)
#16 0xb5894c13 in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011FBC13 
(nsBaseAppShell::NativeEventCallback)
#17 0xb587cfff in ?? () from /usr/lib/firefox-16.0.1/libxul.so 0x011E3FFF 
(nsAppShell::EventProcessorCallback)
#18 0xb742ddd4 in ?? () from /usr/lib/libglib-2.0.so.0
#19 0xb73fba29 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0xb73fdcc1 in ?? () from /usr/lib/libglib-2.0.so.0
#21 0xb73fde4d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#22 0xb6ebb7bd in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7acab05 in wxEventLoop::Run () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#24 0xb7b4ff6e in wxAppBase::MainLoop () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#25 0xb7b4fb41 in wxAppBase::OnRun () from 
/opt/400T/ramdisk/lib/libwx_gtk2_core-2.8.so.0
#26 0x0808e161 in LayoutEngineClass::OnRun ()
#27 0xb7dc032a in wxEntry () from /opt/400T/ramdisk/lib/libwx_base-2.8.so.0
#28 0x0808e973 in main ()

-Original Message-
From:

Proposal for reorganizing test directories

Re: Proposal for reorganizing test directories

Re: Proposal for reorganizing test directories

Re: Proposal for reorganizing test directories

Re: Proposal for reorganizing test directories

RE: deadlock while flash plugin calls posturlnotify

RE: deadlock while flash plugin calls posturlnotify

7 matches

Site Navigation

Mail list logo

Footer information