source-file, header-file, library, resource-file, and framework handler for platform

["Schulhof, Gabriel" <ga...@intel.com>]

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

Re: source-file, header-file, library, resource-file, and framework handler for platform

[Josh Soref <js...@blackberry.com>]

Mark wrote:
> 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.

+1 to not testing empty stubs.

Re: source-file, header-file, library, resource-file, and framework handler for platform

[Mark Koudritsky <ka...@google.com>]

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
>