This PR refactors that diary entry and diary comment tests to remove the associated fixtures.
Note that you may need to remove the fixtures from your test database, since there's nothing in the rails code that removes unnecessary fixtures after their definitions are deleted. Either reload the test database completely, or run "delete from" via psql for diary_entries and diary_comments.
Test DiaryComment body validation
Replaces unnecessary test.
Change the display_name of suspended user fixuture
The original name is reserved, which means the user was invalid,
and this causes problems when building objects using it via
Refactor tests to use factories instead of fixtures
Remove diary_entry and diary_comment fixtures, and refactor tests.
Note that you might need to empty the tables in your local test
database, since the removed fixtures may still linger there.
Remove unneccessary fixture requirement.
So the problem here is that by only creating those two entries we are no longer testing that the right posts get selected because there are no non-matching posts in the database. Much the same applies to the other list tests.
Ugh, implicit tests. Testing negatives are bad enough (just as likely to have an incorrect test as to be successfully testing that something is missing), but implicit ones are the worst. Due to the fixtures our tests are full of implicit negatives.
I'll fix these though, update soon.
In general, our tests have too high ratio of assertions to tests, so it's very hard to discern that e.g. "test_list_user" is supposed to both test that particular things show, and also that other things aren't. But it's nowhere near as bad as e.g. test_new, which crams 5 different tests (even needs comments to delineate them) and 40 assertions into one MegaTest(tm). But I'm trying to avoid biting off too much at once.
Add additional list items to ensure they are not selected
The other list tests already have assetions showing the different
lengths of lists.
I am reasonably experienced rails dev, but I have never seed osmsite codebase. Therefore a question which is quite important to me is - how good/exhaustive are the tests right now? Even if I know the codebase I always start with enrighing the test to maximum extend BEFORE refactoring, because it sort of preserves the quality of the code brought in by years in wild. Basically at this point of development I test the added test by the codebase itself, if I beleive it its correctness :)
If you feel they are comprehensive enough, I would be much more inclined to jump in to refactoring, because it would feel less nervous about breaking any functionality I am not aware of. Of course I would start with syntactic stuff which theoretically should not change the behavior of code at all, but you know - that is a theory.
@gorn The tests are substantial - there are over 290,000 assertions in the test suite. So you can feel confident at getting started with developing.