debugpy-module: how to just run the current test method in pytest

[Peter-Chou]

debugpy-module :module "pytest" works well, but It will run all the tests sequentially until reach the breakpoint, Is there a way to start and just run the current method?

[johannes-mueller]

I am working on that as part of my test-cockpit.el package. There is already a pull request johannes-mueller/test-cockpit.el#27 for dape support for debugpy but it still lacks a bit of testing in practice and documentation.

Basically you use test-cockpit.el to run your unit tests. For python it gives you the option of running the last test as a Dape debug session.

In my first tests it works nicely. Feel free to try it out and give feedback.

[jgarte]

For python it gives you the option of running the last test as a Dape debug session.

Does test-cockpit.el provide a way to debug a particular test and not just the last test?

[jgarte]

Oh ok, I guess I just use test-cockpit-test-function?

Is projectile required to use test-cockpit.el? I'd prefer to not have a dependency on projectile and instead use the builtin project.el. The dape project also prefers to use built-in Emacs APIs as opposed to third-party libraries/APIs.

[svaante]

Moved this to an discussion as it is not something that dape will support but I am happy to refer to test-cockpit.el or an wiki page for these specialized use cases.

[svaante]

I have come around on this issue, but as I don't use any testing frameworks myself.

This feature needs to be implemented by person(s) who are well versed in the testing frameworks and the workflows for each language/adapter.

[johannes-mueller]

As I have written above, I have a rudimentary dape integration in my unit testing frontend test-cockpit.el. However, I am not that much of a debugger user, so I am not that used to usual workflows of using an interactive debugger.

So I would be pleased if you'd give the test-cockpit.el/dape combination a try and help me making the dape integration into test-cockpit.el better.

[jgarte]

The issue with adoption is the setup. If this was just included directly in dape without needing further configurations and 3rd party dependencies it would be a really elegant solution.

@johannes-mueller What do you think of merging test-cockpit.el or just the dape relevant parts into dape and building the logic directly in dape?

[jgarte]

I have come around on this issue, but as I don't use any testing frameworks myself.

This feature needs to be implemented by person(s) who are well versed in the testing frameworks and the workflows for each language/adapter.

Makes sense. It sounds like @johannes-mueller might be the perfect person for the job ;_)

[johannes-mueller]

Merging test-cockpit.el with dape to me doesn't make any sense. The two packages have a totally different scope. Merging the two would make it a hell to maintain and far from elegant. The elegant solution is to have small packages with well defined scope that collaborate well.

I will take a look at the video and see if something similar is possible with the test-cockpit.el/dape combination. I will then post a tutorial and link it here.

Give me some time. I won't be able to do that before January.

[qwertzy-antonio-godinho]

One can use python-pytest package https://github.com/wbolster/emacs-python-pytest which exposes the python-pytest--node-id-def-at-point-treesit function to get the test id, then using it on the args parameter on a dape-configs. I use this: :args (lambda() (when-let* ((test-name (python-pytest--node-id-def-at-point-treesit))) (if test-name '["-k", test-name] (error "No test selected.")))) and it works perfectly to run tests and start dape targetting a given test (at point). Apologies for the formatting but was typed from my phone.

[jgarte]

@qwertzy-antonio-godinho How does this compare to the test-cockpit.el solution proposed above? Have you tried test-cockpit.el?