Adds tests for HTML routes & templates which were not previously covered
Updates existing tests based on template changes
Sorts HTML tests into alphabetised sections
Minor fix of context.back and context.title for the change_password route and template
- Adds tests for HTML routes & templates which were not previously covered
- Updates existing tests based on template changes
- Sorts HTML tests into alphabetised sections
- Minor fix of `context.back` and `context.title` for the `change_password` route and template
Looks good to me. Thanks for fixing the change password title.
The tests that test .post routes passing arguments, and .get routes which make complicated calls to retrieve data, seem more valuable to me as tests, to ensure there are no regressions. The .get tests which just confirm the page renders for a particular route seem less valuable but if its just one test per route that seems pretty manageable.
Looks good to me. Thanks for fixing the change password title.
The tests that test .post routes passing arguments, and .get routes which make complicated calls to retrieve data, seem more valuable to me as tests, to ensure there are no regressions. The .get tests which just confirm the page renders for a particular route seem less valuable but if its just one test per route that seems pretty manageable.
Agreed that we need more test coverage for GET and POST routes. I'd like to learn how to mock the backend data to make those tests as accurate as possible.
The HTML tests are great because they test routes and template rendering in one go. This is especially helpful for templates with more complex context logic; if we mess up a variable name or some tera operation the tests will alert us. I can remember testing by clicking through the whole interface manually in the early days of peach-web 😅 That was tedious.
Thanks for taking a look!
Agreed that we need more test coverage for GET and POST routes. I'd like to learn how to mock the backend data to make those tests as accurate as possible.
The HTML tests are great because they test routes and template rendering in one go. This is especially helpful for templates with more complex context logic; if we mess up a variable name or some tera operation the tests will alert us. I can remember testing by clicking through the whole interface manually in the early days of peach-web 😅 That was tedious.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
notplants
context.backandcontext.titlefor thechange_passwordroute and templateLooks good to me. Thanks for fixing the change password title.
The tests that test .post routes passing arguments, and .get routes which make complicated calls to retrieve data, seem more valuable to me as tests, to ensure there are no regressions. The .get tests which just confirm the page renders for a particular route seem less valuable but if its just one test per route that seems pretty manageable.
Thanks for taking a look!
Agreed that we need more test coverage for GET and POST routes. I'd like to learn how to mock the backend data to make those tests as accurate as possible.
The HTML tests are great because they test routes and template rendering in one go. This is especially helpful for templates with more complex context logic; if we mess up a variable name or some tera operation the tests will alert us. I can remember testing by clicking through the whole interface manually in the early days of peach-web 😅 That was tedious.