4 comments

  • BiteCode_dev 921 days ago
    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?

    • olzhasar 921 days ago
      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/

      • BiteCode_dev 921 days ago
        > 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.

        • olzhasar 921 days ago
          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.
  • blumomo 922 days ago
    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.
    • olzhasar 922 days ago
      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
  • d0mine 921 days ago

       rg --files <dir> | entr -- pytest <args>...
    • olzhasar 921 days ago
      I considered this approach as well. The problem here is that entr will not be able to spot newly added files
  • NelsonMinar 921 days ago
    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.