cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Koudritsky <kam...@google.com>
Subject Re: source-file, header-file, library, resource-file, and framework handler for platform
Date Wed, 02 Apr 2014 14:52:02 GMT
There was a discussion about tests in
cordova-cli<https://www.mail-archive.com/dev@cordova.apache.org/msg11708.html>
back
in November.

Very short summary:
For a filesystem oriented tool we are mocking out way too much of the fs
functionality when testing. This results in brittle hard to maintain tests.

The tests in cordova-cli/e2e were created as a result of that discussion. I
encourage you to take a look at them for a broader view of cordova testing.

While empty stub functions might be needed for compliance with an
interface, personally I don't see any reasons for testing the empty stub
functions in this case.


On Tue, Apr 1, 2014 at 4:50 PM, Schulhof, Gabriel <
gabriel.schulhof@intel.com> wrote:

> Hi!
>
> In [0] Anis explains that each platform has to provide a handler for
> installing/uninstalling at least files of the type "source-file", even
> if they do nothing. Now, AIUI, source-file refers to adding
> platform-specific source code which ends up as "native" code (C#,
> java, objective C ,etc.).
>
> I tend to look at FirefoxOS when I implement corresponding support for
> Tizen, because the two platforms share one important characteristic:
> All functionality needed to provide the APIs offered by plugins is
> itself available as JavaScript. So, there's no need for any "native"
> code. All plugins are basically wrappers around existing JS objects
> provided by the underlying runtime.
>
> So, my (n00bish) questions are:
>
> - Why does FirefoxOS have an implementation of source-file,
> header-file, resource-file, framework, lib-file that does anything
> other than nothing? The fact that there's no firefoxos.spec.js that
> tests any of those install/uninstall routines strongly suggests to me
> that they are, in fact, stubs, or, at worst, incorrect code that
> nevertheless never gets executed.
>
> - Knowing that Tizen will never need to distribute any "native" source
> files, can I just add two empty functions for the install/uninstall of
> each of "source-file", "header-file", "library", etc.?
>
> - If I do the above, I cannot really add a test to tizen.spec.js for a
> function that does nothing. Is it OK to not have such tests?
>
> I ask these questions because I would like to write good tests for the
> Tizen plugman support, as per Anis' final comment[1] on my plugman
> PR[2] and I got kinda stuck trying to write a test for source-file,
> because I copied the implementation verbatim from FirefoxOS, and
> there's no firefoxos.spec.js that would allow me to see how these
> install/uninstall routines are supposed to be tested for a platform
> that will never use them, and synthetically adding source files,
> header files, and stuff like that to the Tizen-specific section of the
> dummy plugin for the specific purpose of testing code that will never
> be used seems like a waste of time.
>
> Please help a n00b out :)
>
>
>
> Gabriel
>
> [0] https://github.com/apache/cordova-plugman/pull/67#discussion_r11004412
> [1]
> https://github.com/apache/cordova-plugman/pull/67#issuecomment-38799304
> [2] https://github.com/apache/cordova-plugman/pull/67
>

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