[TIP] pytest: plugin for CasperJS or javascript integration tests

[Luke Mergner]

On Fri, May 8, 2015 at 8:45 AM, Carl Meyer <carl at oddbird.net> wrote:

> Hi Luke,
>
> On 05/07/2015 07:03 PM, Luke Mergner wrote:
> > I searched the list archives, Stack Overflow, Github, and the internet
> > broadly, but did not see my question answered. This makes me think that
> > I am approaching my problem from the wrong angle.
> >
> > I have a small Flask project which serves a few single-page-applications
> > in several javascript frameworks. My goal is to learn to write js front
> > end web applications. It was much easier for me to build the server in
> > Flask, Jinja2, and SQLAlchemy rather than use Node, which many of the js
> > framework  tutorials assume.
> >
> > On top of my unit tests written in python (pytest) and javascript
> > (jasmine, jest, or karma), I also thought I’d write some integration
> > tests with CasperJS or, later, to try PhantomCSS. The challenge here is
> > that in order to automate the process I have to run a live server
> > example (plenty of these around) while also running the CasperJS
> > process. Since this is a learning project, none of this is necessary,
> > but it helps me to learn how to do things “the right way.”
> >
> > Ideally, I’d like to run the CasperJS integration tests through pytest.
> > I’ve spent some time sketching out a test runner in Python that collects
> > the test_*.js files by name and runs them in a threaded subprocess. It
> > catches the return code, etc., from which I can infer success or
> > failure. (Cool! I wrote my first threaded module.) Then I thought, it
> > sure would be nice to add this as a pytest-plugin, then the server can
> > be started as a fixture and the tests added in the normal test discovery
> > phase.
> >
> > There is actually a Github project that claims to do something like this
> > for Django, but it doesn’t appear load or run the CasperJS files. The
> > documentation for pytest allows for adding tests through the
> > pytest_pycollect_additem hook. However, the functions assume an
> > inspectable python object. Option one is to just add a naive python
> > wrapper around the javascript tests and see what happens.
> >
> > Option two would be to wrap the subprocess call in a way that I can
> > return a subclass of _pytest.python.Function or to create a subclass of
> > _pytest.main.FSCollection which acts like the PyCollection? I’m
> > wondering if I can write subclasses of the Collection/Session and
> > Function classes that I run along with the PyCollection lifecycle. It
> > seems like to do this right, you’d want to give pytest an Item or Node
> > class that mimics what it expects from introspecting python code. This
> > at least is what I think after looking at pytest source.
> >
> > Is this worth pursuing? Is there an obvious alternative, like Selenium?
> > What can anyone recommend in terms of implementation?
>
> Selenium is one obvious alternative, yes (and the one that I use). The
> advantage is that there is a Python Selenium webdriver library
> (https://pypi.python.org/pypi/selenium) so you can write your Selenium
> tests in Python and avoid the "how do I run tests written in JS from
> py.test" problem. You can use Selenium with PhantomJS if you like, but
> you can also run your Selenium tests on real browsers (Firefox, Chrome,
> etc).
>
> If you do still want to run tests written in JS from Python, you can use
> the pytest_collect_file hook to implement arbitrary transformation of
> any type of file into a set of tests (this is what oejskit does). (For
> instance, I have a pytest plugin for testing templates using
> pytest_collect_file; the tests are written in YAML files and
> transparently discovered and run by py.test).
>

To both Carl and Marius,

Thank you for taking the time to respond. Because I don't have programmers
around to ask, having my questions taken seriously is very helpful for my
thought process.

I did see oejskit, but for some reason didn't look closely at the source. I
shall do so. I have little faith in my own skills to innovate, but even a
blind squirrel finds a nut once in a while. Besides, I've noticed that
testing tools really challenge one's understanding of a language.

Perhaps because Javascript is exploding in complexity and the tools are
evolving, transitioning from Python to Javascript (with a sane toolchain
from writing to deploying) has been a real challenge.

Best,

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20150508/50678553/attachment.htm>