Post History
#2: Post edited
- The really _core_ features (posting, voting, commenting, editing) are pretty thoroughly tested; we only really need to test those exhaustively by hand if we're making significant changes to them - otherwise it's a reasonable assumption that if the tests passed then they're working.
- It's as we get outside of core features that testing starts falling off. We have especially limited testing in moderator and admin tooling, because that's not something that most users will ever see.
- We have _no_ tests for the UI. Our existing tests essentially simulate a request and assert various conditions on the response, but there's no real way to test that the UI we've created actually submits an identical request. I always test any new UI I create before pushing it, but especially for major changes this should be a focus.
- ---
Writing tests is probably one of the easiest parts of the application to pick up, so if folks have ideas for test cases, it may well be quicker to write the test yourself and submit a PR. I'll write up a separate post on how to create a test case.
- The really _core_ features (posting, voting, commenting, editing) are pretty thoroughly tested; we only really need to test those exhaustively by hand if we're making significant changes to them - otherwise it's a reasonable assumption that if the tests passed then they're working.
- It's as we get outside of core features that testing starts falling off. We have especially limited testing in moderator and admin tooling, because that's not something that most users will ever see.
- We have _no_ tests for the UI. Our existing tests essentially simulate a request and assert various conditions on the response, but there's no real way to test that the UI we've created actually submits an identical request. I always test any new UI I create before pushing it, but especially for major changes this should be a focus.
- ---
- Writing tests is probably one of the easiest parts of the application to pick up, so if folks have ideas for test cases, it may well be quicker to write the test yourself and submit a PR. I wrote a post on [how to create a test case](https://collab.codidact.org/posts/280493).
#1: Initial revision
The really _core_ features (posting, voting, commenting, editing) are pretty thoroughly tested; we only really need to test those exhaustively by hand if we're making significant changes to them - otherwise it's a reasonable assumption that if the tests passed then they're working. It's as we get outside of core features that testing starts falling off. We have especially limited testing in moderator and admin tooling, because that's not something that most users will ever see. We have _no_ tests for the UI. Our existing tests essentially simulate a request and assert various conditions on the response, but there's no real way to test that the UI we've created actually submits an identical request. I always test any new UI I create before pushing it, but especially for major changes this should be a focus. --- Writing tests is probably one of the easiest parts of the application to pick up, so if folks have ideas for test cases, it may well be quicker to write the test yourself and submit a PR. I'll write up a separate post on how to create a test case.