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