Pycharm is not stopping on breakpoints in the unit tests - since PyCharm 2023.3.2 (Community Edition)

I'm sorry for the trouble being faced. Let's get additional details. Using a  local interpreter with that Python version?

Please provide us with a valid example where this behavior can be reproducible.

I have the same issue on both desktop and notebook.

PyCharm 2023.3.3

Python v. 3.12.1

pytest 8.0.1

Similar  for me, 

It seems to stop on the breakpoint in its flow, but does not reflect that in UI – so the process seem like "hanging".
If I remove all breakpoints – it goes through – but very slowish…

Seems it happens for tests involving odoo models setup – non-odoo ORM tests seem to work smooth.

PS: Same with `PYDEVD_USE_CYTHON=NO`
or removeing cython extention as here: https://intellij-support.jetbrains.com/hc/en-us/community/posts/360010009979-Pycharm-2020-3-Debugger-is-not-working

 

Pycharm 2023.3.4 pro,  pydev debugger (build 233.14475.56)

as well as  7.4.4 (with pytest-odoo plugin v 1.0.0)

============================= test session starts ==============================
platform linux -- Python 3.10.13, pytest-7.4.4, pluggy-1.4.0 -- /home/jurgis/dev/monodoo/venv_siramis/bin/python
cachedir: .pytest_cache
rootdir: /home/jurgis/dev/monodoo
configfile: pytest.ini
plugins: odoo-1.0.0
collecting ... collected 1 item

may be related https://youtrack.jetbrains.com/issue/PY-20186

I had the same symptoms, breakpoints are ignored when trying to debug a unit test (import unittest, run as module). I updated to 2024.1.1, and it worked, but only once. Can't get it to stop at breakpoints that I set via the UI.

PyCharm 2024.1.1 (Community Edition)
Build #PC-241.15989.155, built on April 29, 2024
Runtime version: 17.0.10+1-b1207.14 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 6.5.0
Registry:
 ide.experimental.ui=true
Current Desktop: Budgie:GNOME
 

I found that selecting a different pyhon environment (usign conda) consistently resolves the problem, and shows it again when switching back.

Most significant changes seem to be, with the newer versions working:

• python 3.11.4 → 3.11.7
• pytest 7.4.0 → 7.4.4

Edit: Above versions don't matter, it even when I upgrade the packages in the conda env that doesn't stop at breakpoints, it still doesn't stop.

I've been having the same problem - it's exasperating.

-------------------------------

PyCharm 2023.2.5 (Community Edition)
Build #PC-232.10227.11, built on November 13, 2023
Runtime version: 17.0.9+7-b1000.46 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 2020M
Cores: 8
Registry:
   debugger.new.tool.window.layout=true
   ide.experimental.ui=true

Updated to 2023.2.6 CE, no change.

Updated to 2024.1.2 CE, no change
Invalidated cache, no change

-------------------------------------
OS: Win 10 Pro, Build 10.0.19045, x65, Core i7-9700
Python 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)] on win32
Python 3.11.9 (tags/v3.11.9:de54cf5, Apr  2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)] on win32 (tried both, no difference)
Settings/Interpreter: Python 3.11 venv with pip 24.0, setuptools 70.0.0, wheel 0.43.0 and cbor2 5.6.3
Settings/Debugger/Stepping:  Always do smart step into (checked), Do not step into (unchecked x2)
Python Debugger: tried with Gevent compatible unchecked and checked with no difference

The cbor2 package has the following code in module cbor2.tool:

206  if sequence:
207      objs: Iterable[Any] = iterdecode(infile, tag_hook=my_hook)
208  else:
209      objs = (load(infile, tag_hook=my_hook),)
210
211  for obj in objs:

with breakpoints on 206, 209 and 211.  Debugging stops on 206, a step stops on 209 but a `step into` is ignored, stopping at 211 instead.

load is defined in cbor2._decoder.py:

822  def load(…)
851  return CBORDecoder(…).decode()

as is CBORDecoder:

38  class CBORDecoder:
67  def __init___(self, fp, …):
95  self.fp = fp

209  def _decode(self, ...)
210    if immutable:

with breakpoints set on 95 and 210 (and elsewhere in the same file.  Regardless of where breakpoints are set, CBORDecoder cannot be stepped into and breakpoints within it never stop execution, making it impossible to debug.  In all cases, when stopped at line 211, “objs” is populated correctly, indicating that the decoder executed.

Presumably you can reproduce the same error by installing the cbor2 package and running the tool:

I have the same issue:

PyCharm 2024.1.4
Build #JBC-241.18034.82, built on June 24, 2024
Subscription is active until June 30, 2025.
Runtime version: 17.0.11+1-b1207.24 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11.0
Controller in Remote Development

Python 3.11.9

Pytest 8.2.2

I have the same issue with “unittest” package:

Windows 11.0 Enterprise
Version    10.0.22631 Build 22631

---------latest version----------

PyCharm 2024.1.6 (Community Edition)
Build #PC-241.19072.16, built on August 8, 2024
Runtime version: 17.0.11+1-b1207.30 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.

---------older version----------

PyCharm 2024.1.3 (Community Edition)
Build #PC-241.17890.14, built on June 4, 2024
Runtime version: 17.0.11+1-b1207.24 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.

-----------------

Python 3.12.3 as Conda env

Running the code as “module” (instead of “script”)

And the problem already exists for some months. Can't remember, which version was first with this problems.
 

Hello Daniil,

sure.

While creating the below test samples, I found out, that simple external python source files are working with breakpoints and that just with FastAPI code the breaktpoints do not work.

===================================================

Here's my Conda file (conda env create -f myenv.yml)

name: CaeChassisApiTests_3-12-3
channels:
  - defaults
dependencies:
  - python=3.12.3
  - matplotlib
  - numpy
  - pip
  - psutil
  - pymysql
  - requests
  - scipy
  - socket
  - urllib3
  - xlsxwriter
  - conda-forge::fastapi
  - conda-forge::uvicorn
  - conda-forge::uvicorn-standard
  - conda-forge::python-jose
  - conda-forge::python-multipart
  - conda-forge::pydantic-settings
  - pip:
    - testcontainers

===================================================

And here's a sampe testcase:

import unittest
import requests
import maths_util


class MyTestCase(unittest.TestCase):

    def test_with_external_source_file(self):
        # breakpoint within maths_util.is_odd is working
        self.assertEqual(True, maths_util.is_odd(1))
        self.assertEqual(False, maths_util.is_odd(2))

    def test_with_api(self):
        # breakpoint within api route is not working
        response = requests.post("http://localhost:8000/")
        response_code = response.status_code
        self.assertEqual(200, response_code)


if __name__ == '__main__':
    unittest.main()


===================================================

With the external file maths_util.py, where the breakpoint is working:

def is_odd(value):
    return (value % 2) == 1


===================================================

And the api code, where breakpoint at e.g. “swagger_ui = ..” is not working.

import uvicorn
from fastapi import FastAPI, Depends, Request

app = FastAPI(title="CAE Chassis API")

@app.get("/")
async def welcome(request: Request):
    swagger_ui = str(request.base_url) + 'docs'

    return {"message": f"Welcome to CaeChassisApi",
            "swagger_ui": swagger_ui}

 

A breakpoint at the “swagger_ui = …” within the API route is not working.
Therefore I have no possiblity to debug the API routes/logic :-(

Additionally, the api and unittest file are in the same project/source, whereas the maths_util is in some external source.

Above I forgot the main method, sorry for that. Here again the complete sample project.

=======
api.py
(needs to be started before the unittest)
=======

import uvicorn
from fastapi import FastAPI, Request

app = FastAPI(title="My API")


@app.get("/")
async def welcome(request: Request):
    swagger_ui = str(request.base_url) + 'docs'  # breakpoint here is not working

    return {"message": f"Welcome to my API",
            "swagger_ui": swagger_ui}


if __name__ == "__main__":
    uvicorn.run("api:app", port=8000, reload=True)
 

======================
unittest_pycharm.py
======================

import unittest
import requests
import maths_util


class MyTestCase(unittest.TestCase):

    def test_with_external_source_file(self):
        # breakpoint within maths_util.is_odd is working
        self.assertEqual(True, maths_util.is_odd(1))
        self.assertEqual(False, maths_util.is_odd(2))

    def test_with_api(self):
        # breakpoint within api route is not working
        response = requests.get("http://localhost:8000/")
        response_code = response.status_code
        self.assertEqual(200, response_code)


if __name__ == '__main__':
    unittest.main()

================================
maths_util.py (external source)
================================

def is_odd(value):
    return (value % 2) == 1  # breakpoint here is working


 

I just found out, that breakpoints within the api routes are working, if the api.py is started in debug mode. (First start api.py in debug mode, then start unittests in debug mode.)
If api.py is started in run mode and unittests in debug mode, then api's breakpoints are not working.

This manual api startup might be a workaround and debugging the API is possible again :-)

But it's not solving the complete problem, because in my real big project I have a setUpClass in the unittest, that starts the API.
And that's done in the same mode (run/debug) as the tests themselves, because it's in the same file, and here the api's breakpoints are still not working, whereas the maths_util breakpoint is working.

======================
unittest_pycharm.py
with setUpClass.
api's breakpoints are not working then.
======================

import unittest
import requests
import subprocess
import maths_util

class MyTestCase(unittest.TestCase):
   server_process = None

   @classmethod
   def setUpClass(cls):
       command = ['uvicorn', 'api:app', '--port', '8000']
       MyTestCase.server_process = subprocess.Popen(command, shell=True)

   @classmethod
   def tearDownClass(cls):
       MyTestCase.server_process.kill()

   def test_with_external_source_file(self):
       # breakpoint within maths_util.is_odd is working
       self.assertEqual(True, maths_util.is_odd(1))
       self.assertEqual(False, maths_util.is_odd(2))

   def test_with_api(self):
       # breakpoint within api route is not working
       response = requests.get("http://localhost:8000/")
       response_code = response.status_code
       self.assertEqual(200, response_code)

if __name__ == '__main__':
   unittest.main()
 

Hi Daniil, 

thank you for your answer and your alternative with the remote debug server. I will try that at some time.

I'm just wondering, that my unittest with setupclass won't be able to handle api's breakpoints, because it was working in older PyCharm versions.
And it was so simple, to just have one file, that can be easily run without additional configuration.

Long version - Not sure if it helps, but I just had this issue, not stopping on a breakpoint in a test. (PyCharm 2024.2.1) . Then I noticed I had 2 projects open . Breakpoints were working in one project and not the other. I had just had a bit of a problem morning with python3 being routed to 3.12 and python to 3.10 which caused all sorts of venv issues . (no matter what I did it was using 3.12 via the UI for the venv which caused knock on issues) I had to reinstall pipx and poetry and pyenv was not quite right also. So a fun few hours. Then I had the breakpoint issue on top. 

Short version - For me , it started working when I deleted my venv and rebuilt it.