How to hide the migrations output?

If I run one test via PyCharm I see the migrations output twice:

/home/guettli/projects/lala-env/bin/python /snap/pycharm-professional/230/plugins/python/helpers/pycharm/_jb_pytest_runner.py --target test_models.py::test_address_is_complete
Testing started at 11:42 ...
Launching pytest with arguments test_models.py::test_address_is_complete in /home/guettli/projects/lala-env/src/lala/lala/tests

============================= test session starts ==============================
platform linux -- Python 3.8.5, pytest-6.2.0, py-1.10.0, pluggy-0.13.1 -- /home/guettli/projects/lala-env/bin/python
cachedir: .pytest_cache
django: settings: mysite.settings (from ini)
rootdir: /home/guettli/projects/lala-env/src/lala, configfile: pytest.ini
plugins: django-4.1.0
collecting ... collected 1 item

test_models.py::test_address_is_complete Operations to perform:
  Synchronize unmigrated apps: allauth, colorfield, debug_toolbar, google, messages, staticfiles
  Apply all migrations: account, admin, auth, contenttypes, lala, sessions, sites, socialaccount
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying account.0001_initial... OK
  Applying account.0002_email_max_length... OK
  ... [cut] .... 
Creating test database for alias 'default' ('test_lala')...
Got an error creating the test database: database "test_lala" already exists

Destroying old test database for alias 'default' ('test_lala')...
FAILED                          [100%]
lala/tests/test_models.py:18 (test_address_is_complete)
user = <User: Dr. Foo>

    def test_address_is_complete(user):
        address = user.address
>       assert address.is_complete
E       assert False
E        +  where False = <Address: Address object (1)>.is_complete

test_models.py:21: AssertionError
Destroying test database for alias 'default' ('test_lala')...


Assertion failed


Assertion failed


=================================== FAILURES ===================================
___________________________ test_address_is_complete ___________________________

user = <User: Dr. Foo>

    def test_address_is_complete(user):
        address = user.address
>       assert address.is_complete
E       assert False
E        +  where False = <Address: Address object (1)>.is_complete

test_models.py:21: AssertionError
---------------------------- Captured stdout setup -----------------------------
Operations to perform:
  Synchronize unmigrated apps: allauth, colorfield, debug_toolbar, google, messages, staticfiles
  Apply all migrations: account, admin, auth, contenttypes, lala, sessions, sites, socialaccount
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying account.0001_initial... OK
  Applying account.0002_email_max_length... OK
 ... [cut] ...
---------------------------- Captured stderr setup -----------------------------
Creating test database for alias 'default' ('test_lala')...
Got an error creating the test database: database "test_lala" already exists

Destroying old test database for alias 'default' ('test_lala')...
--------------------------- Captured stderr teardown ---------------------------
Destroying test database for alias 'default' ('test_lala')...
=========================== short test summary info ============================
FAILED test_models.py::test_address_is_complete - assert False
============================== 1 failed in 2.89s ===============================

Process finished with exit code 1


Assertion failed

Assertion failed

How to hide the output which gets created by the migrations?

And why do I see the exception twice?

Start by reproducing test_models.py::test_address_is_complete through PyCharm with the settings in pytest.ini, and compare the migration output with pytest's captured stdout and stderr. Check the pytest-django test-database entry points to determine whether the duplicated output and exception are expected or need a documented configuration change; done means the cause and a reproducible way to hide the unwanted output are established.