Makes sense to me. Can we alias the tests to `cordova selfdiagnostic`? That way I can feel like Geordie LaForge and say, "I'm running a self diagnostic blah blah blah."
On Wed, Aug 7, 2013 at 9:21 AM, Filip Maj <[email protected]> wrote: > Alright, sounds like so far people would like to see it in cordova-cli. > Cool. > > I will let this thread percolate for another day and then start putting > those types of tests into a sub-folder of cordova-cli/spec. I'm thinking: > > cordova-cli > | > `--spec > | > |--integration > `--unit > > .. For splitting up unit tests and integration tests > > On 8/7/13 7:30 AM, "Andrew Grieve" <[email protected]> wrote: > >>Part of CLI, or part of cordova-mobile-spec. >> >>Hopefully we can make CLI fast enough that integration tests won't be an >>issue. >> >> >>On Tue, Aug 6, 2013 at 6:59 PM, Anis KADRI <[email protected]> wrote: >> >>> I wrote some tests for Android back when I was writing those bin/ >>> thingies. I think it makes sense to have some higher level blind tests >>> that run against each platform's bin folder. I'd like it be part of >>> cordova-cli though. We already have 40+ repositories. >>> >>> On Tue, Aug 6, 2013 at 3:52 PM, Jesse <[email protected]> wrote: >>> > I am a +1 either way, not sure which is best. >>> > >>> > @purplecabbage >>> > risingj.com >>> > >>> > >>> > On Tue, Aug 6, 2013 at 3:40 PM, Filip Maj <[email protected]> wrote: >>> > >>> >> You mean, can't the tests exist as part of the cordova-cli tests? I >>> >> suppose they could. The unit tests in cordova-cli are just that: unit >>> >> tests. They do not actually shell out to the platform scripts. This >>> keeps >>> >> the tests focussed and light (run in < 1 second). A good thing if >>>you're >>> >> developing on that project. >>> >> >>> >> Related, Jeff from BlackBerry recently added an "integration" test to >>> >> cordova-cli to actually shell out to certain cordova-cli commands and >>> >> inspect output, but this is brittle: timeouts are usually not met and >>> are >>> >> very system-dependent (having an SSD vs. not is the difference >>>between a >>> >> failing and passing test). >>> >> >>> >> If we broke out the integration tests for the platform scripts, and >>>not >>> >> have them run automatically when you invoke `npm test` within >>> cordova-cli, >>> >> I think it'd be fine. I don't really care where the tests exist, as >>>long >>> >> as a) they exist and b) running them becomes part of the Sanctioned >>> >> Testing And Release Process© (aka STARP) >>> >> >>> >> On 8/6/13 3:27 PM, "Jesse" <[email protected]> wrote: >>> >> >>> >> >Can't this be done vicariously through the cordova-cli tests? >>> >> > >>> >> >@purplecabbage >>> >> >risingj.com >>> >> > >>> >> > >>> >> >On Tue, Aug 6, 2013 at 3:10 PM, Filip Maj <[email protected]> wrote: >>> >> > >>> >> >> Bonus: no longer need to update the wiki article linked-to below >>>and >>> >> >> instead can update the tests. At least this way platform >>>maintainers >>> >> >>will >>> >> >> get a bit more tangible feedback on those scripts, and possibly >>> higher >>> >> >> chance that the scripts get updated :) >>> >> >> >>> >> >> On 8/6/13 3:07 PM, "Filip Maj" <[email protected]> wrote: >>> >> >> >>> >> >> >I would like to propose adding a new repository to cordova called >>> >> >> >platform-spec. >>> >> >> > >>> >> >> >It would be a set of tests that would be run against a cordova-* >>> >> >>platform >>> >> >> >implementation's bin/ folder, testing all of the platform scripts >>> that >>> >> >>we >>> >> >> >have started / attempted to standardize [1]. >>> >> >> > >>> >> >> >Reason: I already see divergence across platform implementations, >>> and >>> >> >>for >>> >> >> >tools that rely on these scripts (ahem, cordova-cli), it would >>>be a >>> big >>> >> >> >bonus :) >>> >> >> > >>> >> >> >It would be nice to introduce running these tests into our >>>testing >>> >> >> >process. At the minimum, we would control script regressions that >>> have >>> >> >> >burned us in the past. >>> >> >> > >>> >> >> >[1] https://wiki.apache.org/cordova/CommandLineToolingDesign >>> >> >> > >>> >> >> >>> >> >> >>> >> >>> >> >>> >
