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.

[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.