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

[Luke Mergner]

On Fri, May 8, 2015 at 2:35 PM, Luke Mergner <lmergner at gmail.com> wrote:

>
>
> 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
>

And to Jim to: Thank you. wsgidriver looks like a very interesting
solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20150508/1f406909/attachment.htm>