Questions

[guinslym]

Great talk!

I don't know where can I had my questions

• ☐ I didn't understand the double sets of parentheses ()() pattern i.e. views.PostUpdateView.as_view()(req, pk=post.pk). Could you elaborate more on this pattern or refer me to a documentation
• ☐ Do you think it will be better to use self.get.client() instead of the RequestFactory() because we can test the template ('birdie/update.html') also. Because right now, we seems to only mock the template. For the benefit of this meetup's workshop using RequestFactory is faster but in a day to day test do you use self.get.client()
• ☐ In tests_views.py in the method the test_security(self): Why we don't write an Assert for 404 like we did for assert post.body == 'New Body Text!', 'Should update the post'
• ☐ Also on the same method why we didn't had a req.user = AnonymousUser() we added instead on the previous test test_post(self). I tought that ever test needs to create a new user session (or object)

[mbrochh]

@guinslym sorry for the late answer, didn't see the email notifications and I was sick for the past four weeks or so.

1. first, we need to create an instance of the view with views.PostUpdateView.as_view() - this call to as_view() will basically turn the class based view into a function. Then we need to actually call that function in order to execute the code in our view, so we do that with (req, pk=post.pk) - these are the arguments, that would be passed into the dispatch function of your class based view.
2. No. Never use self.client.get() because that's slow as hell. I never ever use it. We don't test templates. Ideally, our whole frontend is rendered by ReactJS, which has it's own powerful testing capabilities with something like Jest, for example, so we aren't even using Django's templating language (which is also slow as hell and not suitable for large scale projects which might have hundreds of small partial template components).
3. We can't write an assertion for exceptions. When the exception is thrown, it bubbles up all the way right into the test and then the test crashes with that exception. So if we want to test for 404, we need to use the context processor (with pytest.raises(Http404):). I haven't found a good way to also provide a nice test failure message. I usually just put a code-comment into the context processor code-block, so when the test crashes, the developer will open the test file and then see the comment.
4. The point of this test was to check that one user cannot edit the object of another user. So we created the first user, and we created a Post. The Post will automatically create it's own user, so we will have two users in the system. Then we attached the first user to the request and tried to call the view, but for the object that belongs to the second user. This should raise a 404.

[guinslym]

OMG!!! sorry I didn't see your reply. I am not using Github intensively now as I used to in the summer. Thanks for the reply. I will put your explication into practice.

[mbrochh]

@guinslym don't worry. Github gets overwhelming with messages quickly, so most people reply with huge delay (especially myself). It's normal :)