Task List: Tests that need to be written

[jerivas]

The reason for this list

As Mezzanine grows and expands to cover more and more use cases, every new commit has the potential of inadvertently breaking something somewhere in the code base.

This issue keeps track of the tests that need to be written to ensure certain features are not broken. The goal is to have a comprehensive test base to avoid nasty surprises on new releases.

If you contribute a new feature or fix a bug, please run the current tests, write some for your contributions and comment on this issue to have your tests added as completed. If you can't write the test, comment on this issue to have it added as pending. Lastly, you can contribute by tackling some of the pending tests of this list.

The list

Core

• [x] In the admin, the site drop-down must always be present when multiple sites exist. 7785481507df560cea5b517317ef2a620005ee5d
• [ ] In the admin, the language drop-down must always be present when i18n settings have been defined.
• [ ] In the admin inline items (both tabular and stacked) must be added via the "Add another" button
• [ ] In the admin the RichText and File fields added by dynamic inlines must work and save their values

Pages

• [ ] In the admin, the page tree must allow re-ordering and nesting by drag-n-drop

Blog

• [ ] BlogPostForm must set the hidden fields' initial values and widgets.
• [ ] BlogPost model's get_absolute_url method must build the correct url_name.
• [ ] blog_post_list view must filter posts based on tag, date, category and author.
• [ ] BlogCategoryAdmin's in_menu should return True only if the BlogCategory model is in the ADMIN_MENU_ORDER.
• [ ] PostsRSS class should use the correct title and description based on the Page's existence.
• [ ] PostsRSS's must filter blog posts based on tag, category and author.
• [ ] blog_tags template tag should work correctly.

Filebrowser (media library)

• [ ] Renaming and deleting files
• [ ] Uploading files (respecting the file size and type constraints)
• [ ] Searching for files

Twitter

• [ ] Test all variations of Twitter queries. ASCII only and non-ASCII, User, Search, List, settings defined in Python vs the DB, Python 2 and Python 3. By my count that's 24 different paths that can occur - historically at least one of these is broken, and when fixing it, another will break.

Generic

• [ ] Ensure comment values are correctly persisted through cookies and remain intact when pre-populating the comment form.

[prikhi]

I'm down for writing some tests. I've got a Django project going with 300 some tests.

Some resources for anybody that wants to help: http://test-driven-django-development.readthedocs.org/ http://chimera.labs.oreilly.com/books/1234000000754/index.html http://effectivedjango.com/orm.html#testing http://effectivedjango.com/forms.html#testing

To get a coverage report you can run:

pip install coverage
coverage run --branch --source="mezzanine" setup.py test
coverage report -m
coverage html

I'm not sure how accurate this is, so you should compare it to the tests for that module(I usually use nose and django-nose for testing Django apps/projects).

If we want to test everything thoroughly, some things might have to be refactored into smaller functions. For example, in mezzanine.utils.views.is_spam_akismet, we would have to separate the processing from the http request. Then we could test the processing without relying on being able to query akismet.

Anyways, I'll comb through a couple modules soon and post anything that needs more coverage.

[jerivas]

Thanks a lot @prikhi! Waiting for your contributions.

[prikhi]

I started with one of the easier modules, the blog app. I don't know how in-depth we want to get with these, some might be considered unnecessary, or very low priority.

• Test that the BlogPostForm correctly sets the hidden fields' initial values and widgets
• Test that the BlogPost model's get_absolute_url method builds the correct url_name.
• Test that the blog_post_list view correctly filters based on tag, date, category and author.
• Test that the BlogCategoryAdmin's in_menu method returns True only if the BlogCategory model is in the ADMIN_MENU_ORDER
• Test that the PostsRSS class uses the correct title and description based on the Page's existence.
• Test that the PostsRSS's class correctly filters based on tag, category and author.
• Tests that all blog_tags work correctly.

I didn't go over the management commands, and I'll slowly work through everything else.

[stephenmcd]

That's a really good list.

[jerivas]

Great! I've added everything to the list and broken up tests by categories according to Mezzanine's internal structure.

[prikhi]

Galleries

• Gallery admin pages should include admin/gallery.css
• A description should be generated for new instances of GalleryImage, only if one is not set(partially tested by test_gallery_import).
• A generated description should be the file name with extension removed, single quotes removed and any punctuation replaced by spaces.

[auvipy]

@stephenmcd having a mezzanine coverage report added on repo will be helpful

[stephenmcd]

Would you like to make that happen? That'd be great.

[afs2015]

@stephenmcd: Does that coverage report still need to be added to the repo? If so I can make that happen.

[prikhi]

@afs2015 Looks like it to me. I'm guessing you mean Coveralls.io support? Because I'd wager the repository owner or a collaborator would have to activate the repo on Coveralls. Although you could get the travis.ci end setup.

[spookylukey]

For a lot of Mezzanine functionality, the testing tools provided by Django are inadequate. In particular, tests that use more than one HTTP request. The Django test client is basically useless for this - it doesn't simulate what browsers do closely enough to be of value.

For example, to test the login form changes I did in https://github.com/stephenmcd/mezzanine/pull/1737 you need to:

1. Load the login page
2. 'Click' the 'site' radio button
3. Attempt to log in (with failed password)
4. Ensure that the 'site' radio button is still active.

The tests need to be written at the same high level - otherwise if we use the Django client we have the double pain of tests that are very verbose, and are a very poor indicator that the code actually works.

For this kind of use case, I think you should look into django-webtest, and for anything that needs Javascript, Selenium. You could also use django-functest which attempts to wrap both of these into a usable API. (Disclaimer - django-functest is mainly my work, but has worked well for me on various projects, and has very high test coverage itself).

[jerivas]

@spookylukey reading your comment and exploring django-functest makes me angry! Why? Because I've wasted so much time writing low-level, boilerplate-filled tests for the past few years instead of using it, lol.

This is definitely something we want to incorporate into Mezzanine. Let me know if you're still interested in helping out with a test suite based on django-functest. I think it'll be specially helpful for the admin. For now I've added some key components we want to test to the issue description in light of some things we discovered on #1956

[spookylukey]

@jerivas as I'm no longer an active user of Mezzanine (I was using it mainly for a client), I'm very unlikely to get the time to contribute here. However, I'm still using django-functest in lots of projects, so if you need help with anything on that front let me know and I'll see what I can do. That includes any place where the docs are inadequate.