Using hg as a tool to develop and test Py -> JS

[Jonathan Fine]

Hi

I've another A->B project, which converts special XML to restructured text.  The approach I'm using, which is test driven, seems to work quite well, and I'd like to use for the Python -> JavaScript project.

In the A -> B project I first write a target file B (and check that it behaves as I wish).  This file I commit.  I then write the corresponding source file A.  I then modify the transform so that the new A goes to the new B, and all the previous A's still go the previous B's.

I use "hg st" to regression test (because the A's and B's are all committed) and also to provide the test.

You can see this in action with the recent series of changesets in http://bitbucket.org/jfine/sphinx-ctan-catalogue/.

A nice thing about it is that the A's and B's can be used for preliminary and system documentation.

--
Jonathan

--
You received this message because you are subscribed to the Google Groups "JavaScript for Python programmers" group.
To post to this group, send an email to js...@googlegroups.com.
To unsubscribe from this group, send email to js4py+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/js4py?hl=en-GB.

[Peter Rust]

Nice approach. I’m doing the example-testing for py2js in a similar way.

 

I’m writing the documentation in bitbucket’s wiki syntax (but plan on converting it to ReST, so I can generate docs with Sphinx) – the example-tester reads the Python example, runs it through py2js and affirms that the output exactly matches the corresponding Javascript example.

 

As Ondrej has noted, this approach is useful for “beauty”-testing and example testing, but Niall’s functionality-driven approach is more efficient for full regression testing. The reason is that my example-testing (and your hg testing) uses a character-for-character approach and would be a significant maintenance burden (changing tens or hundreds of tests) whenever we change any whitespace, formatting or the way the Javascript is output (for instance, if we change from vanilla for-loops to a foreach() function).

 

-- peter

[Ondrej Certik]

On Thu, May 6, 2010 at 2:35 PM, Peter Rust <pe...@cornerstonenw.com> wrote:
> Nice approach. I’m doing the example-testing for py2js in a similar way.

Yes, I do the same, first write a test, then the implementation.

>
>
>
> I’m writing the documentation in bitbucket’s wiki syntax (but plan on
> converting it to ReST, so I can generate docs with Sphinx) – the
> example-tester reads the Python example, runs it through py2js and affirms
> that the output exactly matches the corresponding Javascript example.
>
>
>
> As Ondrej has noted, this approach is useful for “beauty”-testing and
> example testing, but Niall’s functionality-driven approach is more efficient
> for full regression testing. The reason is that my example-testing (and your
> hg testing) uses a character-for-character approach and would be a
> significant maintenance burden (changing tens or hundreds of tests) whenever
> we change any whitespace, formatting or the way the Javascript is output
> (for instance, if we change from vanilla for-loops to a foreach() function).

Yes, exactly. I think that functionality is more important, at least
in our group, so that we can get the job done. But since we have the
simple translator, it will be possible to optimize it later, so that
things actually also look good, at least for some special cases, that
can be handled by the JS {} syntax (while using the full, a little bit
messy syntax for the general case).

Ondrej