Skip to content
This repository has been archived by the owner on Feb 28, 2018. It is now read-only.

Refactor tests #228

Open
wants to merge 33 commits into
base: master
Choose a base branch
from
Open

Refactor tests #228

wants to merge 33 commits into from

Conversation

jtemporal
Copy link
Collaborator

As mentioned in #225 in a comment There is a lot of duplicated code that could be shared across test suites.

This is first steps towards removing duplicated code.

A lot needs to be done here and I'm not quite sure this is the best way of doing this. Hoping for some feedback here.

Copy link
Collaborator

@cuducos cuducos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of passing TestCase for a custom method I think a better approach would be a Jarba’s TestCase every test on Jarbas inherit from. For example:

from django.test import TestCase as DjangoTestCase


class TestCase(DjangoTestCase):

   def test_serializer(self, obj, expected, input):
        serialized = obj.serialize(input)
        self.assertEqual(serialized, expected)

This could be at jarbas/core/tests/__init__.py and imported everywhere as from jarbas.core.tests import TestCase (instead of importing TestCase from Django).

Alternatively each app (api, core etc.) could have it’s own TestCase.

What do you think?

@jtemporal
Copy link
Collaborator Author

What do you think?

I like this a lot!

- Moved serializer test method to `__init__`
- Started using new serializer testing method on suspicions command test suite
- Removed serializer test from `shared_tests`
@jtemporal
Copy link
Collaborator Author

hey @cuducos how does dea1f26 looks? in the right path to doing what you mentioned in the PR review?

@cuducos
Copy link
Collaborator

cuducos commented Aug 2, 2017

I like it 👍

How do you like it?

The only thing — tiny tiny thing that I bet has already crossed your mind — is placing this class TestCase in the beginning of the __init__.py — due to its importance. The following auxiliar methods/data/constants could become properties of this object while #178 is still pending (afterwards we can get rid of these auxiliar stuff).

- Created update method on `__init__`
- updated suspicions command test suite to use new update method
- updated receipts text command test suite to use new update method
- Created handler_with_options method on `__init__`
- updated suspicions command test suite to use new handler_with_options method
- updated receipts text command test suite to use new handler_with_options method
- Created handler_without_options method on `__init__`
- updated suspicions command test suite to use new handler_without_options
  method
- updated receipts text command test suite to use new handler_without_options
  method
- Created handler_with_non_existing_file method on `__init__`
- updated suspicions command test suite to use new
  handler_with_non_existing_file method
- updated receipts text command test suite to use new
  handler_with_non_existing_file method
- Created new_command method on `__init__`
- updated suspicions command test suite to use new_command method
- updated receipts text command test suite to use new_command method
- Created add_arguments method on __init__
- updated suspicions command test suite to use new add_arguments method
- updated receipts text command test suite to use new add_arguments
  method
@cuducos
Copy link
Collaborator

cuducos commented Sep 28, 2017

@jtemporal Is this a WIP yet? I fixed a typo and merged master to keep the branch updated. Hope you don't mind. IMHO it's good to merge BTW… just clarify the WIP label so I know what to do ; )

@jtemporal
Copy link
Collaborator Author

Don't think so @cuducos the WIP label was removed on aug 7th ;)

@jtemporal
Copy link
Collaborator Author

@cuducos Now I think only conflict solving is required cc @anaschwendler

@cuducos
Copy link
Collaborator

cuducos commented Oct 2, 2017

@cuducos Now I think only conflict solving is required cc @anaschwendler

Just checked the conflicts. IMHO there are pros and cons there:

Going with what is in refactor-tests contemplates the purpose of this PR, i.e. DRY. However arguably repetitive tests play around with numbers to test batch sizes and that might get lost by using the structure proposed here. IMHO this is not a a big problem — specially because we tend to get rid of batches and work with async tasks (as in #240). I'd go with changes proposed on refactor-tests.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants