+1. Flatter directory structures are virtuous. I also shudder at the thought of a bunch of patches and potential tree redness from scripts that shuffle around our make files for no reason other than adding extra depth.
In most cases, the location of the tests will dictate what types of tests live there. You won't have browser-chrome living next to xpcshell in the same location (pretty sure, please correct me if I'm wrong). In most directories, you'll end up with a single new subdirectory for the existing tests and that doesn't feel worthwhile. ~ rob On 2012-10-25, at 7:06 AM, Justin Lebar <justin.le...@gmail.com> wrote: > I own dom/browser-element/, which has its tests in > dom/browser-element/mochitest. > > 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'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? > > -Justin > > On Thu, Oct 25, 2012 at 9:48 AM, Henrik Skupin <hsku...@gmail.com> wrote: >> 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 > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
