neulab/docprompting-conala huggingface dataset:
logout()  
If your site uses Django’s authentication system, the logout() method can be used to simulate the effect of a user logging out of your site. After you call this method, the test client will have all the cookies and session data cleared to defaults. Subsequent requests will appear to come from an AnonymousUser.
options(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)  
Makes an OPTIONS request on the provided path and returns a Response object. Useful for testing RESTful interfaces. When data is provided, it is used as the request body, and a Content-Type header is set to content_type. The follow, secure and extra arguments act the same as for Client.get().
patch(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)  
Makes a PATCH request on the provided path and returns a Response object. Useful for testing RESTful interfaces. The follow, secure and extra arguments act the same as for Client.get().
put(path, data='', content_type='application/octet-stream', follow=False, secure=False, **extra)  
Makes a PUT request on the provided path and returns a Response object. Useful for testing RESTful interfaces. When data is provided, it is used as the request body, and a Content-Type header is set to content_type. The follow, secure and extra arguments act the same as for Client.get().
Client.session  
A dictionary-like object containing session information. See the session documentation for full details. To modify the session and then save it, it must be stored in a variable first (because a new SessionStore is created every time this property is accessed): def test_something(self):
    session = self.client.session
    session['somekey'] = 'test'
    session.save()
trace(path, follow=False, secure=False, **extra)  
Makes a TRACE request on the provided path and returns a Response object. Useful for simulating diagnostic probes. Unlike the other request methods, data is not provided as a keyword parameter in order to comply with RFC 7231#section-4.3.8, which mandates that TRACE requests must not have a body. The follow, secure, and extra arguments act the same as for Client.get().
class Response  
 
client  
The test client that was used to make the request that resulted in the response. 
  
content  
The body of the response, as a bytestring. This is the final page content as rendered by the view, or any error message. 
  
context  
The template Context instance that was used to render the template that produced the response content. If the rendered page used multiple templates, then context will be a list of Context objects, in the order in which they were rendered. Regardless of the number of templates used during rendering, you can retrieve context values using the [] operator. For example, the context variable name could be retrieved using: >>> response = client.get('/foo/')
>>> response.context['name']
'Arthur'
  Not using Django templates? This attribute is only populated when using the DjangoTemplates backend. If you’re using another template engine, context_data may be a suitable alternative on responses with that attribute.  
  
exc_info  
A tuple of three values that provides information about the unhandled exception, if any, that occurred during the view. The values are (type, value, traceback), the same as returned by Python’s sys.exc_info(). Their meanings are:  
type: The type of the exception. 
value: The exception instance. 
traceback: A traceback object which encapsulates the call stack at the point where the exception originally occurred.  If no exception occurred, then exc_info will be None. 
  
json(**kwargs)  
The body of the response, parsed as JSON. Extra keyword arguments are passed to json.loads(). For example: >>> response = client.get('/foo/')
>>> response.json()['name']
'Arthur'
 If the Content-Type header is not "application/json", then a ValueError will be raised when trying to parse the response. 
  
request  
The request data that stimulated the response. 
  
wsgi_request  
The WSGIRequest instance generated by the test handler that generated the response. 
  
status_code  
The HTTP status of the response, as an integer. For a full list of defined codes, see the IANA status code registry. 
  
templates  
A list of Template instances used to render the final content, in the order they were rendered. For each template in the list, use template.name to get the template’s file name, if the template was loaded from a file. (The name is a string such as 'admin/index.html'.)  Not using Django templates? This attribute is only populated when using the DjangoTemplates backend. If you’re using another template engine, template_name may be a suitable alternative if you only need the name of the template used for rendering.  
  
resolver_match  
An instance of ResolverMatch for the response. You can use the func attribute, for example, to verify the view that served the response: # my_view here is a function based view
self.assertEqual(response.resolver_match.func, my_view)

# class-based views need to be compared by name, as the functions
# generated by as_view() won't be equal
self.assertEqual(response.resolver_match.func.__name__, MyView.as_view().__name__)
 If the given URL is not found, accessing this attribute will raise a Resolver404 exception.
content  
The body of the response, as a bytestring. This is the final page content as rendered by the view, or any error message.
context  
The template Context instance that was used to render the template that produced the response content. If the rendered page used multiple templates, then context will be a list of Context objects, in the order in which they were rendered. Regardless of the number of templates used during rendering, you can retrieve context values using the [] operator. For example, the context variable name could be retrieved using: >>> response = client.get('/foo/')
>>> response.context['name']
'Arthur'
  Not using Django templates? This attribute is only populated when using the DjangoTemplates backend. If you’re using another template engine, context_data may be a suitable alternative on responses with that attribute.
exc_info  
A tuple of three values that provides information about the unhandled exception, if any, that occurred during the view. The values are (type, value, traceback), the same as returned by Python’s sys.exc_info(). Their meanings are:  
type: The type of the exception. 
value: The exception instance. 
traceback: A traceback object which encapsulates the call stack at the point where the exception originally occurred.  If no exception occurred, then exc_info will be None.
json(**kwargs)  
The body of the response, parsed as JSON. Extra keyword arguments are passed to json.loads(). For example: >>> response = client.get('/foo/')
>>> response.json()['name']
'Arthur'
 If the Content-Type header is not "application/json", then a ValueError will be raised when trying to parse the response.
resolver_match  
An instance of ResolverMatch for the response. You can use the func attribute, for example, to verify the view that served the response: # my_view here is a function based view
self.assertEqual(response.resolver_match.func, my_view)

# class-based views need to be compared by name, as the functions
# generated by as_view() won't be equal
self.assertEqual(response.resolver_match.func.__name__, MyView.as_view().__name__)
 If the given URL is not found, accessing this attribute will raise a Resolver404 exception.
status_code  
The HTTP status of the response, as an integer. For a full list of defined codes, see the IANA status code registry.
templates  
A list of Template instances used to render the final content, in the order they were rendered. For each template in the list, use template.name to get the template’s file name, if the template was loaded from a file. (The name is a string such as 'admin/index.html'.)  Not using Django templates? This attribute is only populated when using the DjangoTemplates backend. If you’re using another template engine, template_name may be a suitable alternative if you only need the name of the template used for rendering.
wsgi_request  
The WSGIRequest instance generated by the test handler that generated the response.
DiscoverRunner.build_suite(test_labels=None, **kwargs)  
Constructs a test suite that matches the test labels provided. test_labels is a list of strings describing the tests to be run. A test label can take one of four forms:  
path.to.test_module.TestCase.test_method – Run a single test method in a test case. 
path.to.test_module.TestCase – Run all the test methods in a test case. 
path.to.module – Search for and run all tests in the named Python package or module. 
path/to/directory – Search for and run all tests below the named directory.  If test_labels has a value of None, the test runner will search for tests in all files below the current directory whose names match its pattern (see above).  Deprecated since version 4.0: extra_tests is a list of extra TestCase instances to add to the suite that is executed by the test runner. These extra tests are run in addition to those discovered in the modules listed in test_labels.  Returns a TestSuite instance ready to be run.
DiscoverRunner.get_test_runner_kwargs()  
Returns the keyword arguments to instantiate the DiscoverRunner.test_runner with.
DiscoverRunner.log(msg, level=None)  
 New in Django 4.0.  If a logger is set, logs the message at the given integer logging level (e.g. logging.DEBUG, logging.INFO, or logging.WARNING). Otherwise, the message is printed to the console, respecting the current verbosity. For example, no message will be printed if the verbosity is 0, INFO and above will be printed if the verbosity is at least 1, and DEBUG will be printed if it is at least 2. The level defaults to logging.INFO.
DiscoverRunner.run_checks(databases)  
Runs the system checks on the test databases.
DiscoverRunner.run_suite(suite, **kwargs)  
Runs the test suite. Returns the result produced by the running the test suite.
DiscoverRunner.run_tests(test_labels, **kwargs)  
Run the test suite. test_labels allows you to specify which tests to run and supports several formats (see DiscoverRunner.build_suite() for a list of supported formats).  Deprecated since version 4.0: extra_tests is a list of extra TestCase instances to add to the suite that is executed by the test runner. These extra tests are run in addition to those discovered in the modules listed in test_labels.  This method should return the number of tests that failed.
DiscoverRunner.setup_databases(**kwargs)  
Creates the test databases by calling setup_databases().
DiscoverRunner.setup_test_environment(**kwargs)  
Sets up the test environment by calling setup_test_environment() and setting DEBUG to self.debug_mode (defaults to False).
DiscoverRunner.suite_result(suite, result, **kwargs)  
Computes and returns a return code based on a test suite, and the result from that test suite.
DiscoverRunner.teardown_databases(old_config, **kwargs)  
Destroys the test databases, restoring pre-test conditions by calling teardown_databases().
DiscoverRunner.teardown_test_environment(**kwargs)  
Restores the pre-test environment.
DiscoverRunner.test_loader  
This is the class that loads tests, whether from TestCases or modules or otherwise and bundles them into test suites for the runner to execute. By default it is set to unittest.defaultTestLoader. You can override this attribute if your tests are going to be loaded in unusual ways.
DiscoverRunner.test_runner  
This is the class of the low-level test runner which is used to execute the individual tests and format the results. By default it is set to unittest.TextTestRunner. Despite the unfortunate similarity in naming conventions, this is not the same type of class as DiscoverRunner, which covers a broader set of responsibilities. You can override this attribute to modify the way tests are run and reported.
DiscoverRunner.test_suite  
The class used to build the test suite. By default it is set to unittest.TestSuite. This can be overridden if you wish to implement different logic for collecting tests.
SimpleTestCase.assertContains(response, text, count=None, status_code=200, msg_prefix='', html=False)  
Asserts that a response produced the given status_code and that text appears in its content. If count is provided, text must occur exactly count times in the response. Set html to True to handle text as HTML. The comparison with the response content will be based on HTML semantics instead of character-by-character equality. Whitespace is ignored in most cases, attribute ordering is not significant. See assertHTMLEqual() for more details.
SimpleTestCase.assertFieldOutput(fieldclass, valid, invalid, field_args=None, field_kwargs=None, empty_value='')  
Asserts that a form field behaves correctly with various inputs.    
Parameters:

 
fieldclass – the class of the field to be tested. 
valid – a dictionary mapping valid inputs to their expected cleaned values. 
invalid – a dictionary mapping invalid inputs to one or more raised error messages. 
field_args – the args passed to instantiate the field. 
field_kwargs – the kwargs passed to instantiate the field. 
empty_value – the expected clean output for inputs in empty_values.     For example, the following code tests that an EmailField accepts a@a.com as a valid email address, but rejects aaa with a reasonable error message: self.assertFieldOutput(EmailField, {'a@a.com': 'a@a.com'}, {'aaa': ['Enter a valid email address.']})
SimpleTestCase.assertFormError(response, form, field, errors, msg_prefix='')  
Asserts that a field on a form raises the provided list of errors when rendered on the form. response must be a response instance returned by the test client. form is the name the Form instance was given in the template context of the response. field is the name of the field on the form to check. If field has a value of None, non-field errors (errors you can access via form.non_field_errors()) will be checked. errors is an error string, or a list of error strings, that are expected as a result of form validation.
SimpleTestCase.assertFormsetError(response, formset, form_index, field, errors, msg_prefix='')  
Asserts that the formset raises the provided list of errors when rendered. response must be a response instance returned by the test client. formset is the name the Formset instance was given in the template context of the response. form_index is the number of the form within the Formset. If form_index has a value of None, non-form errors (errors you can access via formset.non_form_errors()) will be checked. field is the name of the field on the form to check. If field has a value of None, non-field errors (errors you can access via form.non_field_errors()) will be checked. errors is an error string, or a list of error strings, that are expected as a result of form validation.
SimpleTestCase.assertHTMLEqual(html1, html2, msg=None)  
Asserts that the strings html1 and html2 are equal. The comparison is based on HTML semantics. The comparison takes following things into account:  Whitespace before and after HTML tags is ignored. All types of whitespace are considered equivalent. All open tags are closed implicitly, e.g. when a surrounding tag is closed or the HTML document ends. Empty tags are equivalent to their self-closing version. The ordering of attributes of an HTML element is not significant. Boolean attributes (like checked) without an argument are equal to attributes that equal in name and value (see the examples). Text, character references, and entity references that refer to the same character are equivalent.  The following examples are valid tests and don’t raise any AssertionError: self.assertHTMLEqual(
    '<p>Hello <b>&#x27;world&#x27;!</p>',
    '''<p>
        Hello   <b>&#39;world&#39;! </b>
    </p>'''
)
self.assertHTMLEqual(
    '<input type="checkbox" checked="checked" id="id_accept_terms" />',
    '<input id="id_accept_terms" type="checkbox" checked>'
)
 html1 and html2 must contain HTML. An AssertionError will be raised if one of them cannot be parsed. Output in case of error can be customized with the msg argument.  Changed in Django 4.0: In older versions, any attribute (not only boolean attributes) without a value was considered equal to an attribute with the same name and value.
SimpleTestCase.assertHTMLNotEqual(html1, html2, msg=None)  
Asserts that the strings html1 and html2 are not equal. The comparison is based on HTML semantics. See assertHTMLEqual() for details. html1 and html2 must contain HTML. An AssertionError will be raised if one of them cannot be parsed. Output in case of error can be customized with the msg argument.
SimpleTestCase.assertInHTML(needle, haystack, count=None, msg_prefix='')  
Asserts that the HTML fragment needle is contained in the haystack one. If the count integer argument is specified, then additionally the number of needle occurrences will be strictly verified. Whitespace in most cases is ignored, and attribute ordering is not significant. See assertHTMLEqual() for more details.
SimpleTestCase.assertJSONEqual(raw, expected_data, msg=None)  
Asserts that the JSON fragments raw and expected_data are equal. Usual JSON non-significant whitespace rules apply as the heavyweight is delegated to the json library. Output in case of error can be customized with the msg argument.
SimpleTestCase.assertJSONNotEqual(raw, expected_data, msg=None)  
Asserts that the JSON fragments raw and expected_data are not equal. See assertJSONEqual() for further details. Output in case of error can be customized with the msg argument.
SimpleTestCase.assertNotContains(response, text, status_code=200, msg_prefix='', html=False)  
Asserts that a response produced the given status_code and that text does not appear in its content. Set html to True to handle text as HTML. The comparison with the response content will be based on HTML semantics instead of character-by-character equality. Whitespace is ignored in most cases, attribute ordering is not significant. See assertHTMLEqual() for more details.
SimpleTestCase.assertRaisesMessage(expected_exception, expected_message, callable, *args, **kwargs)  
SimpleTestCase.assertRaisesMessage(expected_exception, expected_message)  
Asserts that execution of callable raises expected_exception and that expected_message is found in the exception’s message. Any other outcome is reported as a failure. It’s a simpler version of unittest.TestCase.assertRaisesRegex() with the difference that expected_message isn’t treated as a regular expression. If only the expected_exception and expected_message parameters are given, returns a context manager so that the code being tested can be written inline rather than as a function: with self.assertRaisesMessage(ValueError, 'invalid literal for int()'):
    int('a')
SimpleTestCase.assertRedirects(response, expected_url, status_code=302, target_status_code=200, msg_prefix='', fetch_redirect_response=True)  
Asserts that the response returned a status_code redirect status, redirected to expected_url (including any GET data), and that the final page was received with target_status_code. If your request used the follow argument, the expected_url and target_status_code will be the url and status code for the final point of the redirect chain. If fetch_redirect_response is False, the final page won’t be loaded. Since the test client can’t fetch external URLs, this is particularly useful if expected_url isn’t part of your Django app. Scheme is handled correctly when making comparisons between two URLs. If there isn’t any scheme specified in the location where we are redirected to, the original request’s scheme is used. If present, the scheme in expected_url is the one used to make the comparisons to.
SimpleTestCase.assertTemplateNotUsed(response, template_name, msg_prefix='')  
Asserts that the template with the given name was not used in rendering the response. You can use this as a context manager in the same way as assertTemplateUsed().
SimpleTestCase.assertTemplateUsed(response, template_name, msg_prefix='', count=None)  
Asserts that the template with the given name was used in rendering the response. response must be a response instance returned by the test client. template_name should be a string such as 'admin/index.html'. The count argument is an integer indicating the number of times the template should be rendered. Default is None, meaning that the template should be rendered one or more times. You can use this as a context manager, like this: with self.assertTemplateUsed('index.html'):
    render_to_string('index.html')
with self.assertTemplateUsed(template_name='index.html'):
    render_to_string('index.html')
SimpleTestCase.assertURLEqual(url1, url2, msg_prefix='')  
Asserts that two URLs are the same, ignoring the order of query string parameters except for parameters with the same name. For example, /path/?x=1&y=2 is equal to /path/?y=2&x=1, but /path/?a=1&a=2 isn’t equal to /path/?a=2&a=1.
SimpleTestCase.assertWarnsMessage(expected_warning, expected_message, callable, *args, **kwargs)  
SimpleTestCase.assertWarnsMessage(expected_warning, expected_message)  
Analogous to SimpleTestCase.assertRaisesMessage() but for assertWarnsRegex() instead of assertRaisesRegex().
SimpleTestCase.assertXMLEqual(xml1, xml2, msg=None)  
Asserts that the strings xml1 and xml2 are equal. The comparison is based on XML semantics. Similarly to assertHTMLEqual(), the comparison is made on parsed content, hence only semantic differences are considered, not syntax differences. When invalid XML is passed in any parameter, an AssertionError is always raised, even if both strings are identical. XML declaration, document type, processing instructions, and comments are ignored. Only the root element and its children are compared. Output in case of error can be customized with the msg argument.
SimpleTestCase.assertXMLNotEqual(xml1, xml2, msg=None)  
Asserts that the strings xml1 and xml2 are not equal. The comparison is based on XML semantics. See assertXMLEqual() for details. Output in case of error can be customized with the msg argument.
SimpleTestCase.databases  
SimpleTestCase disallows database queries by default. This helps to avoid executing write queries which will affect other tests since each SimpleTestCase test isn’t run in a transaction. If you aren’t concerned about this problem, you can disable this behavior by setting the databases class attribute to '__all__' on your test class.
TransactionTestCase.assertNumQueries(num, func, *args, **kwargs)  
Asserts that when func is called with *args and **kwargs that num database queries are executed. If a "using" key is present in kwargs it is used as the database alias for which to check the number of queries: self.assertNumQueries(7, using='non_default_db')
 If you wish to call a function with a using parameter you can do it by wrapping the call with a lambda to add an extra parameter: self.assertNumQueries(7, lambda: my_function(using=7))
 You can also use this as a context manager: with self.assertNumQueries(2):
    Person.objects.create(name="Aaron")
    Person.objects.create(name="Daniel")
TransactionTestCase.assertQuerysetEqual(qs, values, transform=None, ordered=True, msg=None)  
Asserts that a queryset qs matches a particular iterable of values values. If transform is provided, values is compared to a list produced by applying transform to each member of qs. By default, the comparison is also ordering dependent. If qs doesn’t provide an implicit ordering, you can set the ordered parameter to False, which turns the comparison into a collections.Counter comparison. If the order is undefined (if the given qs isn’t ordered and the comparison is against more than one ordered value), a ValueError is raised. Output in case of error can be customized with the msg argument.  Changed in Django 3.2: The default value of transform argument was changed to None.   New in Django 3.2: Support for direct comparison between querysets was added.   Deprecated since version 3.2: If transform is not provided and values is a list of strings, it’s compared to a list produced by applying repr() to each member of qs. This behavior is deprecated and will be removed in Django 4.1. If you need it, explicitly set transform to repr.