Menu
This is my testing function for views.py which I have mention below:
def test_operation_page(self):
url = reverse('operation')
response = self.client.get(url)
self.assertEqual(response.status_code, 200)
self.assertTemplateUsed(response, 'abc.html')
self.assertContains(response, '<b>BOOK id having certain title:</b>')
This is the error I am having while testing my views
AssertionError: Database queries to 'default' are not allowed in SimpleTestCase subclasses. Either subclass TestCase or TransactionTestCase to ensure proper test isolation or add 'default' to home.tests.TestViews.databases to silence this failure.
This is my views.py
def operation(request):
queryset=Mytable.objects.filter(title="The Diary of Virginia Woolf Volume Five: 1936-1941").values('bookid')
textset=list(Mytable.objects.order_by('-bookid').values('title'))
context={
'key1' : queryset,
'key2' : textset
}
return render(request,'abc.html',context)
This is my urls.py
urlpatterns = [
path('admin/', admin.site.urls),
path('',v.index,name='index'),
path('abc/',v.operation,name='operation')
]
621
The only exceptions that are not visible to the test client are Http404 , PermissionDenied, SystemExit, and SuspiciousOperation. Django catches these exceptions internally and converts them into the appropriate HTTP response codes. In these cases, you can check response.status_code in your test.
Firstly, your tests must be async def methods on the test class (in order to give them an asynchronous context). Django will automatically detect any async def tests and wrap them so they run in their own event loop. If you are testing from an asynchronous function, you must also use the asynchronous test client.
Both of the ways are valid. AssertionError is inherited from Exception class, when this exception occurs and raises AssertionError there are two ways to handle, either the user handles it or the default exception handler. In Example 1 we have seen how the default exception handler does the work.
The test client is a Python class that acts as a dummy web browser, allowing you to test your views and interact with your Django-powered application programmatically. Simulate GET and POST requests on a URL and observe the response – everything from low-level HTTP (result headers and status codes) to page content.
It would be something like either you inherit the TestCase or TransactionTestCase or by using the same SimpleTestCase in the following way
class CustomClass(django.test.SimpleTestCase):
databases = '__all__'
...
Earlier SimpleTestCase had dependency on allow_database_queries = True which is depreciated since django version 2.2.
This attribute is deprecated in favor of databases. The previous behavior of allow_database_queries = True can be achieved by setting databases = '__all__'.
https://docs.djangoproject.com/en/2.2/topics/testing/tools/#django.test.SimpleTestCase.databases
123
As it states in the docs under SimpleTestCase, "If your tests make any database queries, use subclasses TransactionTestCase or TestCase."
The error that you are getting is telling you that your view is trying to execute a database query in a subclass of SimpleTestCase. You should change what TestCase class you are using - that should solve the error.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
