librelist archives

Re: [flask] Re: Flaskesque unit testing

From:

danjac354@gmail.com

Date:

2010-11-25 @ 23:18

Flask-Testing currently does some syntactic sugar (assert_404 etc)
which can be ported over as simple functions (or just do assert
response.status_code == 404 etc, if you prefer).

It also provides a few utilities e.g. to help with JSON testing. This
requires e.g. being able to set the Response class.

It should be quite doable as you describe, something along these lines:

from flaskext.testing import Assert, assert_200

from myproject import app # instance or factory function

api = Assert(app)

@api.context
def test_something(client):
     response = client.get("/")
     assert_200(response)

There would need to be an easy way to hook into the context manager.
For example, in addition to setting up the test_request_context, I
might need to do some DB setup. In SQLAlchemy for example I need to
create/drop the db, remove the current session, etc.

So we might need something like this:

@api.before
def before():
    db.create_db()

@api.after
def after()
    db.session.remove()
    db.drop_db()

These would need to be run inside of the test_request_context call.

On 25 November 2010 22:56, Dag Odenhall <dag.odenhall@gmail.com> wrote:
> On Thu, 2010-11-25 at 22:31 +0000, danjac354@gmail.com wrote:
>> This also looks like it might work very nicely with Flask. You could
>> create a @context decorator function to return a Flask request
>> context, for example.
>
> I want to make it easier to "inherit" a context. Currently you have to
> do this whole dance,
>
> @my.context
> def context():
>    with imported_context():
>        yield
>
> Which seems a little overkill to me, would be nice to easily subclass
> Tests and add a default context, i.e. a FlaskTests that runs in a
> test_request_context.
>
>> The existing Flask-Testing unittest methods
>> (assert_404 etc) could be ported over quite nicely.
>
> Continuing on the previous point, I'd like a Werkzeug test client that
> returns the result wrapped in Assert. Such a client could be yielded
> from the default context. This makes it easy to assert things like the
> status code.
>
> api = FlaskTests()
>
> @api.test
> def returns_json(client):
>    response = client.get('/api/')
>    assert response.status_code == 200
>    assert response.mimetype == 'application/json'
>
> In this example, 'response' is a response object wrapped in
> attest.Assert. Note that the 'assert' keywords here are optional, I just
> add them for clarity/readability and to avoid some potential silently
> passing tests. The actual assertions are done in Assert.__eq__.
>
>> It wasn't quite clear from the docs, but how do you manage a
>> "teardown" ? For example, if I need to create/destroy a test database?
>
> They're just context managers, so just do stuff after the yield. Might
> need to wrap in try-finally though *shouldn't* be needed as Attest will
> catch all exceptions anyway. You can also yield from a context manager
> such as contextlib.closing() or something similar built into your DB
> toolkit.
>
> @my.context
> def context():
>    with db.open() as conn:
>        yield conn
>
> A similar example exists in the docs:
> http://packages.python.org/Attest/api.html#attest.Tests.context
>
>

On Thu, 2010-11-25 at 23:18 +0000, danjac354@gmail.com wrote:

> There would need to be an easy way to hook into the context manager.
> For example, in addition to setting up the test_request_context, I
> might need to do some DB setup. In SQLAlchemy for example I need to
> create/drop the db, remove the current session, etc. 



@api.context
def context():
    with app.test_request_context():
        db.create_db()
        yield
        db.session.remove()
        db.drop_db()


If 'test_request_context' was made a default context for a FlaskTests
class or similar, you could also drop that with statement. I just had an
idea how to do that, the Tests class could inject all contexts in a
contexts attribute and then you could subclass like so:


class FlaskTests(Tests):
    contexts = (app.test_request_context,)


And to generalize for any app,


class FlaskTests(Tests):

    def __init__(self, app):
        Tests.__init__(self)
        self.contexts = (app.test_request_context,)


Not sure yet if this is the best idea, but it's one idea. A contrived
example obviously, the real thing would handle app factories and
probably a nice way to subclass FlaskTests too for setting your
application so you don't have to do it for each FlaskTests instance.

On Fri, 2010-11-26 at 00:35 +0100, Dag Odenhall wrote:
> Not sure yet if this is the best idea, but it's one idea.

Pushed a different solution: you can have multiple @tests.context. This
allows the use of factory functions:


def flask_tests(app):
    tests = Tests()
    @tests.context
    def request_context():
        with app.test_request_context():
            yield Assert(app.test_client())
    return tests


api = flask_tests(app)

@api.context
def not_overiding(): pass

@api.test
def json(client):
    response = client.get('/api/')
    response.mimetype == 'application/json'
    response.status_code == 200


You could also have helper functions for adding contexts with less
boilerplate:


def with_db(tests):
    @tests.context
    def connect():
        with db.open() as conn:
            yield conn

api = flask_tests(app)
with_db(api)

@api.test
def json(client, conn): pass


Is this a good solution? It feels right to me, and in relation to Flask
and the tradition of create_app() and init_app() etc.