-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
how to testing flask-login? #40
Comments
What do you mean? On Mon, 25 Jan 2016 5:38 am tanyewei [email protected] wrote:
|
I guess he has trouble with cookies because client doesn't have the expected scope. |
What is the expected scope? You can always explicitly create required scope by passing any headers into the client. Example of using @pytest.fixture
def user():
"""Should return an user instance."""
@pytest.fixture
def credentials(user):
return [('Authentication', user.get_auth_token())]
def test_endpoint(client, credentials):
res = client.get(url_for('endpoint'), headers=credentials) |
If there's nothing else I'm closing this issue. @tanyewei feel free to reopen it. |
I suspect he's having trouble with Say you have a fixture like this: @pytest.fixture
def logged_in_user(request, test_user):
flask_login.login_user(test_user)
request.addfinalizer(flask_login.logout_user) And a test like this: @pytest.mark.usefixtures('logged_in_user')
def test_protected(client):
resp = client.get('/protected')
assert resp.status_code == 401 Because the pytest-flask test client pushes a new context, the |
@tmehlinger thank you for clarifications. For now request context has been pushed to ensure the |
hi, everybody. I am facing the same problem. @vitalk, I am not really got what you mean. but I find that, use client.post('login') would work. but login_user(user) fails. I am new to flask, really confuse now. |
Hi @hackrole! As mentioned above, the |
As of flask-login release 0.4.0 the |
Struggling with this as well - Is there a method or setup I can do to make sure the client does a post to the login part of our site such as client_authenticated |
Hi guys, I was also struggling with testing with authenticated user for flask-login, and here is my working snippet: @pytest.fixture()
def test_with_authenticated_user(app):
@login_manager.request_loader
def load_user_from_request(request):
return User.query.first() |
I was struggling with this too.
WARNING: Be careful with this approach if you share the app between multiple tests - like when you are using a fixture with scope session, as the overwritten login_manager.request_loader will not get reset. One of my tests was failing somewhat randomly when using pytest-xdist and it took me a while to realize that it is due to the 'residual' of the login_manager.request_loader In the end when I wanted to do an unauthenticated call after overwriting the '@app.login_manager.request_loader' to return the test user, I needed to overwrite it again, so it doesn't return anything, making it work for the unauthenticated user scenario:
|
I did something similar to @zoltan-fedor but with a slight twist. Here are the relevant parts: @pytest.fixture
def app():
app = create_app('TestConfig')
with app.app_context():
yield app
@pytest.fixture
def authenticated_request(app):
with app.test_request_context():
# Here we're not overloading the login manager, we're just directly logging in a user
# with whatever parameters we want. The user should only be logged in for the test,
# so you're not polluting the other tests.
yield flask_login.login_user(User('a', 'username', 'c', 'd'))
@pytest.mark.usefixtures("authenticated_request")
def test_empty_predicates():
# The logic of your test goes here |
Someone solutions? |
Hi all, since I am struggling with the issue as well, which is the best way to approach it? I need to test some features which are available just to some user levels so disabling auth is a no go for me. Thanks! |
The way I understand the guidelines, as documented here, the suggested approach (don't know if it's the best one) was already mentioned by @stevenmanton Namely, if this is your view:
your test would, within a request context, manually log in a user and then call the view function
unfortunately, you can't use the client fixture because it simulates a full request, meaning you can't control the request context it generates. |
I can't get this to work. I want to run my test like a regular user (see only the user data, denied access to some views). from slots_tracker_server import app as flask_app
@pytest.fixture(scope="session", autouse=True)
def client():
flask_client = flask_app.test_client() to initialize my app and DB. Why cann't I use something like: flask_login.login_user(Users.objects().first()) or flask_client.login_user(Users.objects().first()) in order to simulate a user? also, I'm using
in order to force most views to be protected. can you please help? thanks. |
I hit this too, in tests trying to simulate an AJAX client that first hits a |
The fixture scope mentioned by @jab is the cause of the incorrect login status. I have a complete example here, the problem lies in the cleanup work done in the app fixture: @pytest.fixture
def app():
print('Hit')
_app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///test.db'
with _app.app_context():
db.create_all()
yield _app
os.remove('test.db') In this case, the default fixture scope is 'function', which means that each test case will be re-executed once, If you use So that the database is rebuilt , the data created in other places is lost, so the user cannot be queried here, so the status is not logged in yet. To fix it, just modify the value of a larger scope, such as session, package or module:
|
This ended up working for me: @pytest.fixture(scope='function')
def admin_client(app, db):
with app.test_request_context(), app.test_client() as _admin_context:
admin = User(
name='Test Admin',
username='test_admin',
email='[email protected]',
role='Admin',
)
db.session.add(admin)
db.session.commit()
login_user(admin)
yield _admin_context
logout_user() This gives you a context where the |
how to testing flask-login?
The text was updated successfully, but these errors were encountered: