Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
The original name is reserved, which means the user was invalid, and this causes problems when building objects using it via associations.
Note that you might need to empty the tables in your local test database, since the removed fixtures may still linger there.
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.
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.