5

I'm trying to integrate PHPunit into a big project, everything seems fine except it seems that all methods that rely on ob_start() will result in a risky test.

Reading online, it seems risky tests are such tests which execute code not covered by the testing method. However, I haven't used the @covers annotation at all, And this happens only on ob_start().

So a few questions :

  1. Is it possible to resolve this issue?
  2. Is there something inherently wrong with ob_start when it comes to testing?
  3. Is there a way around it?(if not possible to resolve it).

The use case is using a framework who's views are returned(instead of sent to the browser), Codeigniter comes as a classic example, where you can return views. Returning views depend on ob_start(). Thanks alot!

Patrick
  • 3,289
  • 2
  • 18
  • 31

1 Answers1

4

The solution is two fold, as it revolves around two issues I had.

  1. Regarding the specific problem, using views in a framework(codeigniter), I simply used a mock for the loader, so I implemented an empty function that doesn't actually load and outputs html.
  2. Regarding the actual issue I had with PHPunit's behavior, it seems that PHPunit(4.5) will assume a test is Risky if using ob_start and ob_clean, However when using ob_get_clean the testing works as expected. I'm not sure why as I didn't dive into the code itself, but that solved it for me
Patrick
  • 3,289
  • 2
  • 18
  • 31
  • // Fetch the buffered output then ob_get_clean .... thank you!
    `$out = output(); $out = ob_get_clean();`     – Andrew Smith Jul 14 '15 at 17:34
  • Thanks for point two, I'm creating a prettier var_dump function :) – Ricky Boyce Sep 28 '17 at 00:02
  • its a risky test because flush leave the output in the buffer so the next test would start with a dirty buffer, ob_get_clean wipes the buffer out so nothing left to interfere with other tests – MikeT Aug 11 '22 at 10:59