ydaniv / django-rest-assured Goto Github PK

Need to resolve the pending pagination issues in #9

Why is this file necessary? pytest is supposed to discover all class / function tests by itself...

Also: currently it's causing problems with testing on Django 1.9 because some changes to tests and/or the app registry (I'm not 100% sure which).

when? :)

Currently tests fail pretty badly on errors from DB.
I'm pretty much clueless of their origin.

This is a very useful project! But it notes:

Tests run against:

    Django 1.6 - 1.11.
    Django REST Framework 2.4.3 - 3.6.
    Python 2.7, 3.3 - 3.6 (3.2 should work but is not tested).

Can you test against the most recent versions (Django 2.2, DRF 3.9, Python 3.7) as well and update? Thank you!

Hello there!
I will start trying to use the project today: it seems interesting.
One question, why aren't the requirements pinned?
Thanks! Hope to contribute here soon.

Shouldn't these be dictionaries?

    create_data = {'name', 'documentary'}
    update_data = {'name', 'horror'}

First, awesome library. Going to save me soooooo much time....

Second, what is the pattern for "negative" testing? Meaning, say I have an API that is public-read, private-write: (using, say the IsAuthenticatedOrReadOnly permissions for django-rest-framework)

I can test that anonymous users are able to Read, and I can test that authenticated users can Read or Write. But what is the approach to ensure that anonymous users CAN NOT Write? Obviously if I send anonymous users through the ReadWrite mixin it will fail (like in the tutorial), but that's not what i'm looking for: I'm looking for a test that affirmatively asserts the negative permissions (if that makes any sense at all.... ) :-)

Basically, how do I write: assertEqual([anonymous user tries to PUT], [HTTP_401_UNAUTHORIZED])

Thanks...

cc @maryokhin

I've added tests using pytest and integrated Travis CI.

Current status can be checked here: https://travis-ci.org/ydaniv/django-rest-assured

Will work for the next few days on fixing the failing ones, most should be easy.

Help is welcome (:

~Y

Problem
I am getting an error that a django models.OneToOneField must be unique.

======================================================================
FAIL: test_create (work_ready.tests.TestWorkReady)
Send request to the create view endpoint, verify and return the response.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/rest_assured/testcases.py", line 272, in test_create
    self.assertEqual(response.status_code, status.HTTP_201_CREATED, getattr(response, 'data', response))
AssertionError: {'worker': [u'This field must be unique.']}

The cause of this error is saving 2 different model instances with the same primary key.
What is happening is that in my model I have a django models.OneToOneField:

class WorkReady(models.Model):
    """Help Worker get ready for their first/next job"""
    worker = models.OneToOneField(Worker, related_name='work_ready')
    ...

Using CreateAPITestCaseMixin requires:

class (CreateAPITestCaseMixin, BaseRESTAPITestCase):
    ...

In BaseRESTAPITestCase.setUp() the object is getting created:

# create the object
self.object = self.get_object(self.get_factory_class())

So an object gets created in BaseRESTAPITestCase.setUp(), then another object gets created in CreateAPITestCaseMixin.test_create()

def test_create(self, data=None, **kwargs):
    response = self.get_create_response(data, **kwargs)   # second object gets created

You also can't not create an object in setUp() as CreateAPITestCaseMixin.test_create() requires self.object, which is set in BaseRESTAPITestCase.setUp().

def test_create(self, data=None, **kwargs):
    ...
    # self.object required here
    created = self.object.__class__.objects.get(
        **{self.lookup_field: self.get_lookup_from_response(response.data)})
    ...

Possible solution

1. BaseRESTAPITestCase.setUp() should not create self.object when testing create method
2. CreateAPITestCaseMixin.test_create() shouldn't rely on self.object to test that the object was created

Thanks for making django-rest-assured!

Happy to submit a PR for this issue.

The maintainer is unresponsive.

should validate hyperlink in _update_check_db not just id to ForeignKey

any way to use with model_mummy instead of factory boy?

The test now looks for 'resutls' inside response.data and this needs to be configurable.

I've got a working instance on one of my projects, using WebTest. Is there a room in today's OS market for such a project.

My intention is to have it based on both LiveServerTestCase and django-webtests' WebTestCase.

Thoughts? Comments?

Because it casts the response data to text in default, the comparisons for numerical, date, and boolean types are failing.
Ex:

self.assertEqual(value, text_type(data[attr]))
E   AssertionError: 10032 != '10032'

self.assertEqual(value, text_type(data[attr]))
E   AssertionError: '2017-03-13 12:21:13.796885+00:00' != '2017-03-13T12:21:13+0000'

self.assertEqual(value, text_type(data[attr]))
E   AssertionError: False != 'False'

I think we should determine the type of fields instead of simply casting into text.

at testcases.UpdateAPITestCaseMixin.get_update_results:408 we have following:

return getattr(self, 'update_results', data)

This means that if self doesn't have 'update_results' attribute 'data' is returned. But as 'update_results' is always defined at testcases:350:

update_results = None

'data' will never be returned on this function, right?

This implies that (testcases.py:377) 'results' will never receive 'data' via 'self.get_update_results(data)' with code above:

        if results is None:
            results = self.get_update_results(data)
            self.__results = results

If I don't define 'udapte_results' when inheriting a Testcase class, a _update_check_db function will always define results as an empty dict

        if results is None:
            results = self.__results or {}

and then (still _update_check_db:480):

self.assertEqual(attribute, results.get(key, value))

will use default parameter 'value' in 'get' from 'data'.

Finally, I don't see anything broken because tests still pass normally. But I think sounds kinda strange.

Sorry if I misunderstood something.

Cheers