More Edit Account tests

[rodney757]

We should create tests for the edit account view.

[Ben Sturmfels]

I'm going to be bold and close this ticket.

My feeling is that adding tests for the sake if it is hard (ie. not bitesized) and not very useful since the code already works. I'd suggest insisting on tests when the code is next changed to verify that the changes don't break things.

Regards,
Ben

[berkerpeksag]

Alternatively, we can just remove the bitesized keyword. We can also just unit test form classes instead of functional testing like we already did in ​http://git.savannah.gnu.org/cgit/mediagoblin.git/tree/mediagoblin/tests/test_edit.py#n28

[Ben Sturmfels]

I don't mean to be overzealous in closing this out, but if no-one has touched it in two years it seems like it might not be worth keeping in the ticket system.

What sort of things would you want to test on the form classes? Apart from my change which you've just been reviewing, there's not much in the way of functionality in edit/forms.py.

[berkerpeksag]

but if no-one has touched it in two years it seems like it might not be worth keeping in the ticket system.

We have some 10+ years old issues at bugs.python.org :) Unfortunately, this is one of the "features" of volunteer-based free and open source software projects.

What sort of things would you want to test on the form classes?

Field types, default values, error messages for example. Most importantly, we can detect potential future regressions in wtforms by testing user creation/editing forms.

[Ben Sturmfels]

We have some 10+ years old issues at bugs.python.org :) Unfortunately, this is one of the "features" of volunteer-based free and open source software projects.

I'm not sure that I'd hold up a 10 year old bug report as an example of something to strive towards. I think that sort of clutter just reduces the effectiveness of the bug reporting tool.

Field types, default values, error messages for example. Most importantly, we can detect potential future regressions in wtforms by testing user creation/editing forms.

That's still a fairly vague description as to what would make this ticket complete. My understanding is that it is best practise to only test the project's code, not that of underlying libraries. Regression tests for wtforms should be contributed to the wtforms test suite, not MediaGoblin's.

[berkerpeksag]

Yes, of course we are going to test our forms, not wtforms itself, but also we might be rely on a untested behavior of wtforms.

I can add a test as an example and share it here for future contributors.