Show HN: Pytest-watcher – A working alternative to Pytest-watch | Hacker News Reader

Show HN: Pytest-watcher – A working alternative to Pytest-watch

github.com

26 pointsolzhasar10 comments

What's the benefit of doing this instead of just using the watchmedo command from watchdog directly ?

    watchmedo shell-command --patterns="*.py" --ignore-directories --recursive . -c "pytest"

As a bonus, watchmedo works for your server, your bundler, you task queue process, etc.

It seems that there is no need to create one tool per command you wish to run. Or am I missing something? Do you only reload tests that are related to the code change?

First, I think for many users typing:

  ptw .

is a lot simpler than typing:

  watchmedo shell-command --patterns="\*.py" --ignore-directories --recursive . -c "pytest"

Second, I personally faced problems with suggested approach. I use neovim with ale plugin that automatically formats my code with black every time I save python file. That's two saves instead of one. In that case watchmedo will trigger pytest to run twice, which is usually not the desired behavior. Sometimes you also just save your file multiple times quickly and you want pytest to run only once with latest changes in mind.

In my tool, there is a 0.5 seconds delay (configurable --delay). pytest-watcher will wait this time for other changes before starting pytest.

Regarding running tests for changed code only, there is a pytest-testmon plugin which does exactly that. It can be used together with pytest-watcher. Here is the link:

https://testmon.org/

> that case watchmedo will trigger pytest to run twice,

That's what the --drop options is for. It's better than delay, since it drops any event while the command is running, no matter the time it took.

> First, I think for many users typing: ... is a lot simpler than typing:...

I think somebody using pytest is perfectly capable of doing:

alias ptw='watchmedo shell-command --patterns="*.py" --ignore-directories --recursive . -c "pytest" --drop'

Or putting that in a makefile, a dodo.py file or what have you.

I don’t think that —drop is better than delay in case of tests. Quite contrary, one usually wants them to run after latest save not the first one.

As an alternative, there is also `pytest --looponfail`.

Install pytest and pytest-xdist, then run:

    pytest --looponfail

It watches for file changes and automatically re-runs any previously failed test. Runs the complete test suite (or a selected subset of tests via additional arguments) if none failed.

This indeed works. But the problem with this approach is that pytest-xdist outputs result losing all colors. Viewing colorful output is more convenient for many users

   rg --files <dir> | entr -- pytest <args>...

I considered this approach as well. The problem here is that entr will not be able to spot newly added files

I recently switched to VS.Code and was surprised there was no support for continuously running tests on save. The PyTest integration is great, just no looping option.

This may work for you

https://marketplace.visualstudio.com/items?itemName=LittleFo...

Reply on news.ycombinator.com