You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an error occurs, cover should set the process exit code to something other than zero. This allows calling tools to detect a test failure. At the moment, if a test fails, our build server claims success because cover exits with an exit code of zero.
The text was updated successfully, but these errors were encountered:
One question to get your opinion on: how would you denote a Cover error vs an error induced by the actual program? For example, if I exit with exit code 1, how would you know if it is because Cover failed or your program failed?
Note that if your program failed, Cover will still generate code coverage information. If Cover itself dies, no coverage is likely.
For me, it is irrelevant. I just need to know that the process failed so that the build process can halt. I would imagine that is the case for almost everyone else as well. It is easy enough to diagnose the issue afterward and run the build process again, possibly disabling node-cover, if that is determined to be the cause of the problem. If the tests fail and I get some coverage info, that's ok. It will just be ignored. If it is important to someone to distinguish between node and target program failure, one possibility is to return 1 for node and 2 for program. Then write something to stdout that is grep-able. However, I would be surprised if that is relevant to anyone.
When an error occurs, cover should set the process exit code to something other than zero. This allows calling tools to detect a test failure. At the moment, if a test fails, our build server claims success because cover exits with an exit code of zero.
The text was updated successfully, but these errors were encountered: