cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <>
Subject Re: We need better contributions from new people
Date Thu, 13 Jun 2013 15:16:10 GMT
No offense, but have you ever run all the manual tests? Doing this is a
time consuming process and is unnecessary in most cases.

We automated both mobile-spec and the JUnit tests so that they get run by
developers on a regular basis. You can write what you want on the wiki but
it doesn't mean the people writing the code will follow it (myself

All I'm asking for is some testing, not all the tests to be run. Going from
one extreme to another isn't going to be helpful.
On Jun 13, 2013 8:02 AM, "Marcel Kinard" <> wrote:

> On Jun 12, 2013, at 6:10 PM, Joe Bowser <> wrote:
> > The problem with this approach is that we shouldn't rely on just
> > mobile-spec for our testing...
> >
> > The fact is that on Android, if you're doing changes to the core, you
> > should be running the JUnit tests included with the project...
> Sounds good. So how about the following:
> - the developer (contributor or committer) is responsible to test their
> own code and correct any problems before a pull request is submitted
> (contributor authored) or it lands in the stream (committer authored). The
> testing includes both verifying the function they added/touched, plus
> running the test suites to verify there are no regressions.
> - When we say "run the test suites" this includes the automated tests in
> mobile-spec, the manual tests in mobile-spec and any platform-specific unit
> tests (i.e., cordova-android/test, cordova-ios/CordovaLibTests, etc.)
> - if a pull request, the committer should sanity check the contributor's
> code. This should include at least a simple visual inspection.
> - if a pull request, the committer should see that the contributor tested
> it. A simple comment in Jira should suffice, similar to how Mike and Lisa
> worked as contributors here:
> If there is consensus, I can add the above verbage to the wiki.
> Do we want to go as far as the following?
> - every new function and defect fix should include an automated test
> (where reasonably feasible) that lands in a test suite at the same time as
> the new function / fix.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message