Oh, ho, ho. BizarroWorld™ packaging directory structure, huh? Yeah. That's... that's your problem. 🤣

I hope you don't mind, but I've migrated this into a Q&A discussion format for readability and clarity. Please don't mind! You have totally valid concerns, but they probably intersect better with the forum format. Okay. So...

As you've correctly surmised:

...pytest must be executing the tests in some manner that doesn't involve importing the package, thereby sidestepping the beartype_this_package hook.

That's it. That's totally it. You've nailed it in one. This might be surprising. Like @beartype, pytest itself makes heavy use of import hooks to do its perfidious magic. assert rewriting, test collection, and more? Yeah. That's import hooks all the way down. To preserve compatibility with pytest import hooks, @beartype import hooks actually go waaaaaay out of their way to interoperate cleanly with what pytest wants to do.

What pytest mostly wants to do is for wonderful packagers such as yourself to cleanly separate tests from non-tests. Instead, you've interleaved your tests (e.g., the my_package.cursed_test submodule) with your non-test code (e.g., the my_package.__init__ submodule). Technically, there probably are really convoluted workarounds to achieve this. Pragmatically, it's best to never even go there. Interleaving tests and non-tests together in the same my_package/ directory structure is a recipe for cumbersome migraine-inducing discussions like this. In the immortal words of 80's pop-punk trash outfit Offspring:

You gotta keep 'em separated.

pytest really wants you to structure your package files like this:

my_package/           # <-- *PYTEST HATES TESTS IN YOUR MAIN PACKAGE*
    __init__.py       # <-- beartype_this_package() for the win!
    curse_it.py       # <-- no tests in here -- only logical business logic

my_package_test/      # <-- *PYTEST LOVES TESTS OVER HERE*
    test_curse_it.py  # <-- all tests over here

So. What do those two new my_package.curse_it and my_package_test.test_curse_it submodules look like? Behold! A worky test suite that curses like a drunken sailor while otherwise behaving sanely:

• In the my_package.curse_it submodule:

  def curse_like_a_sailor():
      x: int = "nope"
      assert True

• In the my_package_test.test_curse_it submodule:

  def test_curse_like_a_sailor():
      from beartype.roar import BeartypeDoorHintViolation
      from my_package.curse_it import curse_like_a_sailor
      from pytest import raises
  
      with raises(BeartypeDoorHintViolation):
          curse_like_a_sailor()

Totally works. Right?

$ ls
my_package/        my_package_test/
$ pytest
================================================= test session starts =================================================
platform linux -- Python 3.8.19, pytest-7.2.1, pluggy-1.0.0
rootdir: /home/leycec/tmp/
collected 1 item                                                                                                      

my_package_test/test_curse_it.py .                                                                                    [100%]

================================================== 1 passed in 0.31s ==================================================

@beartype and pytest 🫶 each other. @beartype was built from the ground up to play nicely with pytest. But @beartype and pytest both have hard and fast rules concerning this integration, which mostly just reduces to: ^...waitforit

You gotta keep 'em separated.

^{pytest (diva in front) + @beartype (guy in back): a match made in GitHub}

Thank you so much for responding so quickly and comprehensively! I have fixed my crazy directory structure in my toy example, and I believe my problem still remains. Namely, I don't get any errors and don't know how to set things in such a way that I would get errors for incorrect type hints in variable assignments in test files.

Alternatively, I'm still making some crazy mistake... Here's my setup.

my_package
├── implementation.py
└── __init__.py
my_package_test
├── __init__.py
└── test_cursed_things.py

my_package/implementation.py:

def totally_valid_function(x: int) -> int:
    return x

my_package/__init__.py

from beartype.claw import beartype_this_package

beartype_this_package()

my_package_test/__init__.py

from beartype.claw import beartype_this_package

beartype_this_package()

my_package_test/test_cursed_things.py

from beartype import beartype
from my_package.implementation import totally_valid_function


@beartype
def test_curses():
    x: int = "nope"

    assert True

running pytest ./

========================= test session starts =========================
platform linux -- Python 3.8.19, pytest-8.3.2, pluggy-1.5.0
rootdir: /home/how_python_wurk_idk/Projects/test
collected 1 item                                                      

my_package_test/test_cursed_things.py .                         [100%]

========================== 1 passed in 0.14s ==========================

Oh, ho, ho. Madness intensifies. So you want to apply beartype.claw import hooks to both your main codebase and your test suite, huh? That's... a fascinating idea. You're the first @beartype user brave enough to sacrifice your sanity for that. It's not easy being brave. Applying beartype.claw import hooks to your main codebase is, of course, trivial. It's applying beartype.claw import hooks to your test suite that's the issue. That might be infeasible. </gulp>

How familiar are you with pytest hooks, plugins, and conftest.py scripts? My strong suspicion is that you'll need to "go there." pytest appears to be circumventing standard packaging semantics and importlib machinery in your test suite. Kinda sounds like a horrifying can of worms poised to explode all over your face, honestly.

Was there a pressing reason that you needed beartype_this_package() to apply to your test suite? Are your authoring your own pytest plugin, for example, that you needed to runtime type-check with @beartype? May the Gods help us, for pytest has surely abandoned us in our time of testing need. 😿