Symfony phpunit test 'Killed'

Question

I get my repository using entityManager, but if I try to access it in any way, it seems that the test starts endless cycle and then kills itself. It does not matter if I try to find an element inside or just print the whole variable the test just dies.

public function testStuff()
    {
        $moduleRepository = $this->entityManager->getRepository(Module::class);
        fwrite(STDERR, print_r("asd", TRUE));

        //$result = $moduleRepository->find(1);
        fwrite(STDERR, print_r($moduleRepository, TRUE));
    }

Output:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

Testing 
asdKilled

Without accessing the variable:

public function testStuff()
    {
        $moduleRepository = $this->entityManager->getRepository(Module::class);
        fwrite(STDERR, print_r("asd", TRUE));

        //$result = $moduleRepository->find(1);
        //fwrite(STDERR, print_r($moduleRepository, TRUE));
    }

Output:

PHPUnit 9.5.5 by Sebastian Bergmann and contributors.

Testing 
asdmodule (App\Tests\module)
 ☢ Stuff

Time: 00:00.266, Memory: 22.00 MB


OK, but incomplete, skipped, or risky tests!
Tests: 1, Assertions: 0, Risky: 1.

I understand that by not calling the variable getRepository is not even started, but from the first test you can see that the method is done without any errors, the problem is only there when you try to access it.

What is $moduleRepository? What do you get if you just var_dump() that? — duncan, Jun 16 '21 at 19:28
its a database repository, and you can't output using var_dump inside a test — Alpha Kenny Buddy, Jun 16 '21 at 20:25
`print_r()` can be a bit quirky. Try using `var_dump()` or if you need some more fancy stuff the [VarDumper with its phpunit integration](https://symfony.com/doc/current/components/var_dumper.html#using-the-vardumper-component-in-your-phpunit-test-suite). — dbrumann, Jun 17 '21 at 06:01
@dbrumann the problem is not in printing it out, I can't do anything with that variable it just kills my test as soon as I use it in any way. — Alpha Kenny Buddy, Jun 17 '21 at 06:24
That's odd. Did you write your own repository or are you using the default from Doctrine? Can you show the code of the repository (only the class structure with constructor) and maybe the output of `bin/console debug:container ModuleRepository)? Do you have the same problem in the code or just in the test? — dbrumann, Jun 17 '21 at 07:21
@dbrumann for some reason after I tried to use assert it started to work, but if I delete assert and try to print out elements from the repository the code crashes. — Alpha Kenny Buddy, Jun 17 '21 at 07:37
I'm sorry, I don't have enough details to help you. Maybe you can create a small reproducer project, which can be used for debugging and finding out if this is an issue with Symfony, Doctrine or something else. — dbrumann, Jun 17 '21 at 12:26

score 1 · Answer 1 · answered Jun 20 '21 at 15:52

This does not specifically answer your question, but might be important, also for future visitors, to understand the "Killed" part.

This is Unix error message "Killed" and other users are also seeing it in tests (here also database related).

This is not Phpunit that is outputting it, but it is the kernel killing the PHP process that runs Phpunit, likely the Out Of Memory Killer (OOM Killer) and as you can imagine, being Out of memory (OOM) is not a state you'd like to have - and so does not your kernel.

Similar what you describe:

it seems that the test starts endless cycle

and likely one that consumes more and more memory until the kernel kills the process.

Then the "Killed" message is printed in the terminal.

Most likely for your scenario the $this->entityManager is not properly initialized/configured as you locate the point within the test-method.

Sometimes it also happens with clean-up code that goes wrong, but that is less likely. More often it is the configuration of the test fixture.

Now this may not give you the exact place and solution, but hopefully enough pointers. As these kind of errors can be very hard to debug, it can help to create a new test-case in isolation to test for this behaviour only and to reproduce it with as little test-code as possible.

Run the test-suite only with that test-case and when its easy to reproduce, check with debugging what kicks in the endless loop. Often it is a specific condition, e.g. missing configuration or initialization.

As the case is already isolated, doing it in isolation often leads to better and faster results. And in case you run into a similiar problem in the future, you already have a test-case that shows how it can be done (or improved).

I found a same problem from 11 years ago. https://user.phpunit.narkive.com/nWAarPD5/var-dump-some-exception-goes-into-infinite-loop-in-phpunit-context I still haven't figured it out why would I be able to access the variables using assert, but not in any other way. It makes the testing really hard since I can only see the value of the variable at the end of the code, and finding a problem in the middle of my program is almost impossible. — Alpha Kenny Buddy, Jun 21 '21 at 07:18
@belenka3000: Is xdebug loaded when you experience this? Are you using mocks when you experience this? Backup globals? And are you able to isolate this in a test-case and only execute that test-case? var_dump() can go into endless recursion. xdebug may prevent that when set-up. complex systems like an entity manager may have references in both ways (parent <-> child) and then a dump goes like that: parent -> child -> parent -> child -> ... (never stops). the var_dump() will consume all memory then. so might not be the configuration, but the dump. — hakre, Jun 21 '21 at 08:39
Mocking works fine, I tried it with another test. Right now I'm pulling real data from database, and that's when the problem occurs. I'm really new to phpunit and I'm working on a really big project, currently I'm having more problems understanding the back-end than writing a test for it, and I think it's a back-end related problem, which no one noticed it, because no one ever tried testing it. — Alpha Kenny Buddy, Jun 21 '21 at 09:53
Just something I would do: Try to reproduce without mocking. Mocking can also create side-effects and they can be memory intensive / hard crashing. — hakre, Jun 21 '21 at 12:04

score 0 · Accepted Answer · answered Jun 17 '21 at 07:37

0

$this->assertEquals(25,count($moduleRepository));

After I tried to assert my results it worked.

answered Jun 17 '21 at 07:37

Alpha Kenny Buddy

132
9

Symfony phpunit test 'Killed'

2 Answers2