Skip to content
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

Set up unit tests #110

Open
MattF-NSIDC opened this issue Aug 22, 2023 · 3 comments · May be fixed by #125
Open

Set up unit tests #110

MattF-NSIDC opened this issue Aug 22, 2023 · 3 comments · May be fixed by #125

Comments

@MattF-NSIDC
Copy link

MattF-NSIDC commented Aug 22, 2023

We'd like to be able to test that, for example, a page correctly renders a survey or response's attributes. We recently changed a name field to short_name, and this required manual testing to ensure all the forms continued to work properly.

Should we enable jinja's strict mode always, or just for these tests to help us find such errors?

We discussed and decided we'd like to spend an hour pairing on this.

@rmarow
Copy link
Contributor

rmarow commented Aug 22, 2023

Look into flask docs

@rmarow rmarow moved this from Todo to In Progress in US AON Benefit Tool Aug 25, 2023
@rmarow rmarow linked a pull request Aug 25, 2023 that will close this issue
@rmarow
Copy link
Contributor

rmarow commented Sep 7, 2023

some notes:

  • What are our goals for this ticket ? (when is it okay to close)
  • Now that we are not requiring login in dev our test_logged_out is failing - should I delete that?
  • Mocking in Sqlite

@MattF-NSIDC
Copy link
Author

MattF-NSIDC commented Sep 7, 2023

What are our goals for this ticket ? (when is it okay to close)

Mocking in Sqlite

I think the original goal was to pair for an hour or so to establish a unit test pattern that could be continued going forward. I think we have a few working tests and can consider that objective closed. But I think we need a new ticket to set up a pattern for doing tests that require DB mocks, which I think we can use our new SQLite functionality for. We can create fixtures that initialize the database like we do with db.init command fresh for each test. And we can create other tests that build on top of a freshly-initialized database with mock data. We could even have multiple tests in a row that depend on each other by controlling the "scope" of the fixtures (e.g. for a class or module, share this fixture and clean up only when the whole class or module is done).

What do you think?

Now that we are not requiring login in dev our test_logged_out is failing - should I delete that?

We can override that environment variable for certain tests to require login when that's what we want to test! Testing "logged out" I think is a good case for that because we don't need to involve Google.

@mfisher87 mfisher87 moved this from In Progress to Todo in US AON Benefit Tool Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

Successfully merging a pull request may close this issue.

2 participants