Re^5: debug output from TODO with Test::More

And there is ZERO value in that.

Sorry, you are quite wrong.

TODO tests are an extremely valuable tool when you are dealing with volatile data. For example: you fetch data by querying an API, and you know it returns bad results under condition X. So you code a workaround for condition X, and you write a TODO test that you expect to fail. When the test begins to pass you get notification because of the TODO, and you remove the workaround for condition X.

This is a common strategy. The fact that you aren't familiar with it is no reason to be dismissive of other people's experience.

From the Test::More docs:

You don't skip tests which are failing because there's a bug in your program, or for which you don't yet have code written. For that you use TODO.

When do I use SKIP vs. TODO?

If it's something the user might not be able to do, use SKIP. This includes optional modules that aren't installed, running under an OS that doesn't have some feature (like fork() or symlinks), or maybe you need an Internet connection and one isn't available.

If it's something the programmer hasn't done yet, use TODO. This is for any code you haven't written yet, or bugs you have yet to fix, but want to put tests in your testing script (always a good idea).

The way forward always starts with a minimal test.

Comment on Re^5: debug output from TODO with Test::More Download Code

Replies are listed 'Best First'.
Re^6: debug output from TODO with Test::More by Anonymous Monk on Jan 13, 2017 at 22:02 UTC
"TODO tests are an extremely valuable tool when you are dealing with volatile data." Hence why you mock the service and provide data that is not volatile. "If it's something the programmer hasn't done yet, use TODO." Nah, SKIP does that much better. But thanks for your opinion. Meanwhile, the real world calls ...	[reply]
Re^7: debug output from TODO with Test::More by 1nickt (Canon) on Jan 14, 2017 at 02:23 UTC
Your ignorance may feel like bliss, but you are not even half as clever as you think you are. Mocking the service is the exact opposite of what is needed. You mock a service when you want to shield your test from the volatility of the data. I am running tests precisely to observe when the data changes. `TODO` is the right tool for that job, clueless though you may be about the job and the tool. The way forward always starts with a minimal test.	[reply] [d/l]