Gazelle considers both `test_*.py` and `*_test.py` files to be `py_test` targets.

[dougthor42]

🐞 bug report

Affected Rule

• gazelle

Is this a regression?

Nope! Just unexpected behavior.

Description

A typical python project will use only one of *_test.py or test_*.py to name test files.

However, gazelle will make py_test targets for both types:

https://github.com/bazelbuild/rules_python/blob/e86252ffd6d1a1bf32ae99933acc5ab49b78ec1e/gazelle/python/generate.go#L116

https://github.com/bazelbuild/rules_python/blob/e86252ffd6d1a1bf32ae99933acc5ab49b78ec1e/gazelle/python/generate.go#L198

This can lead to unexpected behavior:

Example 1: unit test utilities

Assume that a project uses *_test.py for unit/integration tests. Using pytest, the config would be:

[tool.pytest.ini_options]
python_files = ["*_test.py"]

Also assume that there needs to be some utilities related to testing. A typical solution would be to make a test_utils.py file because that does not get collected by the pytest test runner.

gazelle will incorrectly (at least according to the user) make:

py_test(
    name = "test_utils",
    srcs = ["test_utils.py"],
)

The user expects a py_library instead.

Example 2: Non-code tests, such as electrical or physical testing

Code that deals with electrical or physical testing (voltage, current, vibration, pressure, etc) is typically called test_foo or foo_test. For example, code that determines the breakdown voltage of a part might be called test_breakdown_voltage.py. Code might also need to create collections or suites of non-code tests, and would live in test_suites.py.

Again, according to the user, gazelle will incorrectly make py_test targets for such instead of py_library targets.

🔬 Minimal Reproduction

1. Make test_foo.py
2. Make foo_test.py
3. Run gazelle
4. See that both were generated as py_test targets.

🔥 Exception or Error

N/A

🌍 Your Environment

Operating System:

  
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux rodete
Release:        n/a
Codename:       rodete
  

Output of bazel version:

  
$ bazel version
Starting local Bazel server and connecting to it...
Build label: 7.1.0
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Mon Mar 11 17:55:31 2024 (1710179731)
Build timestamp: 1710179731
Build timestamp as int: 1710179731
  

Rules_python version:

  
0.31.0 @ bdb2aa2e5c0ca435918037aa3568c0b0c4c9c1ab
  

Anything else relevant?

Don't think so.

[dougthor42]

This can be solved by adding a directive (I seem to love directives...). Something like:

# gazelle:python_test_file_pattern *_test.py

I imagine the directive supporting a comma-separated list of globs with the default obviously matching the existing behavior:

# The default.
# N.B.: We probably would want to change the 2nd to include the extension: "test_*.py"
# gazelle:python_test_file_pattern *_test.py,test_*

# only *_test.py will be made into `py_test` targets
# gazelle:python_test_file_pattern *_test.py

# any glob is actually valid.
# matches "A_test_a.py", "A_test_1.py", "B_test_f.py", etc., and the literal "unittest.py"
# gazelle:python_test_file_pattern [A-Z]_test_?.py,unittest.py

If this sounds like a good solution LMK and I'll be happy to take a stab at it.

[wingsofovnia]

It occurred to me today as well and I literally have test_utils.py file :) Is test_*.py even a common convention in Python?

[dougthor42]

Is test_*.py even a common convention in Python?

Yes, though it seems like it's going out of style in favor of *_test.py (but that might just be observation/recency bias).

• pytest docs use test_*.py on the Getting Started page.
• unittest's test discovery still uses test*.py by default (though note the lack of underscore).
• nose2 uses test_*.py by default but can be configured.

[aignas]

The suggested implementation sounds good to me. I think the default behaviour even had a few tests to ensure that people can create libraries with 'test' in the file. But that might have changed at some point.