The essence of my question is to try to understand and clarify for myself to achieve what goal are the descendants of the base class TestCase written (for example from TestCase from docs.python.org )? Similar to the TestCase-e class, also found in other libraries, for example: in jUnit, nUnit, etc.

For a more substantive discussion, let's take some example code in which there are several functionalities. Suppose there is a views.py module included in Blueprint auth . Recall that Blueprint is a term from the world of microfreamer Flask-a. In this example, several functionalities: changing the password, getting a token, adding and deleting a user.

Here is the code for this views.py module:

@auth.route('/users/register', methods=['POST']) @administrator_required def register_user(): pass @auth.route('/users/unregister', methods=['DELETE']) @administrator_required def unregister_user(): pass @auth.route('/users/change-password', methods=['PUT']) def change_password(): pass @auth.route('/users/token') @credentials_required def generate_token(): pass

Again, this is just an example of a piece of code in which several functionalities. One could also give a mathematical class, where there are also several possibilities: addition modulo, entropy calculation, etc.

How to write unit tests to cover the checks of the code under test in which several functionalities. To pimera for this blueprint? What test suite should contain such a test class (a descendant from TestCase)?

  1. Maybe the test suite should cover the entire \ blueprint component?
  2. Perhaps you need a test suite that covers only one functionality. Thus, several test classes appear: TokenTest, RegisterUserTest, UnregisterUserTest, ChangePasswordTest?
  3. Or is it necessary to write a set of tests for a single method / function that is part of the implementation of the tested functionality?

UPD :

My question is not about "How to use Flask?" and not in “How to write a unit test for a Flask application?” I repeat once again, a piece from a Flask application is given only as an example, because it is difficult for me to argue abstractly and best of all with bringing any piece of code.

  • the title and the body of the question do not match: you can use TestCase subclasses without mentioning flask, and vice versa you can test the flask functions without explicitly creating TestCase subclasses. It is better to break into two questions or leave only the question to which you really want to get an answer. - jfs
  • Why not fit? What exactly is this expressed? Just the goal is traced to find out what tests should be contained in the descendants of Test-Case? In other words, what is his purpose? - sys_dev

2 answers 2

If to speak strictly, then:

  • One test is not a class, but one method test_* (i.e. it is the piece of code that tests the selected feature). A class, therefore, is simply a combination of several tests.
  • Inheritance from a particular class is optional and can be made as a requirement only by a specific testing framework. Freymovrka needs this to provide common functionality - before / after hooks, data providers, arbitrary test names, and so on.

How to test this blueprint

No You can test the individual functions included in this blueprint, but the organization and performance of this blueprint lies in flask, and therefore it is not necessary to test it. You can test the application as a whole - write tests directly on the TK / SRS, which check the compliance of the execution with the idea, and then they will be organized in the form of scripts that check the aspect of the application.

What test suite should contain such a test class (a descendant from TestCase)?

In the case of unit testing, it is customary to cover one class with one tests case. In the case of testing a higher level, one aspect is usually taken - for example, checking the download of files - and all tests are written there that check this aspect. In case they get too much, they are divided by functionality. In general, there are no clear settings; The main thing is that one test case completely absorbs the scope of functionality that is aimed at: one class - all tests for this class are collected, the session system checks all work with sessions, authorization checks - all scenarios that are possible during authorization. If there is authorization through a large number of providers - by the case for each of the providers. Ideally, of course, everything should be as atomic as possible (and then each test case would consist of one test), but this requires too much effort.

The specific choice of the three options depends on the framework and methodology. Writing various scenarios is BDD, and, in my opinion, the most sensible solution at the system testing level; The choice between the first and third depends on the amount of code in the tests.

  • I correctly understood, 1) that the test framework allows you to organize testing not only modular, but also integration? 2) And if so, then the first question before writing a test is this: what type of test are we going to write: modular or integration? - sys_dev
  • What the framework allows is dependent on the framework. In system testing, simple assertions are not very applicable, and sometimes it is required to continue the script, even despite the conditions. On the second question - in general, yes, first understand what is required to test, then implement it. - etki

What is the main goal for the descendant classes from TestCase?

A child of TestCase can group several related (thematically) tests ( test*() methods), their common setting ( setUp() method - is executed before each test*() method) and completion ( tearDown() method - is executed after each test ) and provides many convenient methods ( assertEqual() , assertRaises() , etc methods) that help to write individual test-components themselves.

How do I write unit tests to cover this Blueprint?

Blueprint is essentially a reusable web application. Therefore , you can also test blueprint as a normal application :

 class FlaskrTestCase(unittest.TestCase): def setUp(self): self.db_fd, flaskr.app.config['DATABASE'] = tempfile.mkstemp() self.app = flaskr.app.test_client() flaskr.init_db() def tearDown(self): os.close(self.db_fd) os.unlink(flaskr.app.config['DATABASE']) def test_empty_db(self): rv = self.app.get('/') assert 'No entries here so far' in rv.data

The core here is test_client() and the corresponding queries ( .get('/') in the example).

What does "thematically related" mean? Maybe one function is being tested? Or maybe one class? Or maybe one functionality?

@sys_dev: this can mean everything that the author of tests wants, that is, not necessarily to follow functions, classes, "functionality".

Formally, these are all tests that have common setUp / tearDown methods and are combined under the same name (the name of a subclass - if it is hard to think of a name, this indicates that the tests are not well connected).

  • I apologize, but it is not clear yet. What do your "thematically related" mean? Maybe one function is being tested? Or maybe one class? Or maybe one functionality? In other words, I want to know what is the connectivity criterion? - sys_dev
  • @sys_dev: updated the answer. - jfs
  • Thank! Updated your question. My question is not about using Flask. It lies in the strategy and ways of organizing the unit test code when writing descendants from the base classes. After all, similar TestCase from the Python library are also found in other programming languages, for example in jUnit - sys_dev
  • @sys_dev: this is a topic for a whole book (or several). Here is a list of books on unit testing for an example - jfs
  • I updated my question again. Yes, I agree with you and I read books, for example, now "Art of Unit Testing", but! None has yet seen a clear and precise explanation of my question; ( - sys_dev