I am using JUnit 4.12 and this is my current understanding of the following APIs I use frequently:
assumeTrue: if expression evaluates to false, test will halt and be
ignored
assertTrue: if condition is false, throws an AssertionError
assertEquals: if they are not equal, an AssertionError is thrown with
the given message
assertNotNull: if it is null, throws an AssertionError
However, I am unable to get clarity on couple of things:
my understanding is that only for assumeTrue, the tests will exit but the very definition of assert is that the program should exit when the statement evaluates to false
when the test throws an AssertionError, does it exit the test case or continue executing the remaining steps?
can the tests be considered pass, even if they throw an AssertionError or are the tests considered fail?
assumeTrue means that the test shouldn't run. It does not mean your code is broken and most runners will treat this test as "ignored"
An AssertionError means the test has failed. No more steps in that test case (the single method) will be run. It would be pointless to do so as the test has already failed
The test has failed. If you want to negate the meaning of a test there are other ways to do that, e.g. replace assertNull with assertNotNull
Related
I wanna raise Exception under certain circumstances, say some if or case conditions. I'm doing this for returning some failure status if certain condition if not satisfied, so I could know and deal with that.
I have tried several methods but none could raise Exception only under some condition:
select some column does not exist: Exception is raised when parsing.
divide some value by 0: null is returned, instead of raising Exception
make some assertation in UDF: assertations are not allowed in UDF
I wonder if it's possible deliberately Exception to terminate the program.
e.g. (not legal HiveQL)
SELECT CASE some_condition WHEN true THEN continue ELSE exception END AS condition
Take a look at assert_true UDF, looks like it's exactly what you need.
hive> select assert_true (2<1);
OK
Failed with exception java.io.IOException:org.apache.hadoop.hive.ql.metadata.HiveException: ASSERT_TRUE(): assertion failed.
Time taken: 0.497 seconds
I want to know what is the usefulness of tdie comparing to Java exceptions in talend knowing that when an exception occur tdie exit the job and is passing the error to tlogcatcher .The same thing can be done by java exceptions (they also can be received by tlogcatcher and they exit the job ).
So why java exceptions are not enough for logging so we use tdie?/what is the limits of java exceptions.
I don't use tDie after a component exception (like Component-->oncomponenterror-->tDie . As you stated, the java exception is caught : if you put a tDie, you'll only have 2 lines logged instead of just one.
I use tDie to put an end to a job if a condition is not met : for example , I can test the number of lines inserted in a DB, if it is 0 , I call tDie to end the job (with tDBOutput--if-->tDie , with a test on number of lines inserted inside the if condition).
This is more like a functional error than a technical one that I want to catch in this case.
I'm making a custom plugin to query a database for user info to aide customer support. My backend is slack.
Everytime I start the bot command I'm greeted with:
Computer says nooo. See logs for details:
catching classes that do not inherit from BaseException is not allowed
I'm not sure if this is warning me that I'm attempting to catch an exception that isn't a BaseClass in my code or if an unknown exception was raised and caught elsewhere outside of my plugin.
To debug I tried:
try:
do_the_thing()
except (TypeError, ValueError) as e:
return('Something went wrong.')
I also tried:
try:
do_the_thing()
except Exception as e:
return('Something went wrong.')
And I still get the errbot admonition. Note that the command still runs and does the right thing where there is no exception raised by do_the_thing().
It means that:
Somewhere in your code you have an except ... statement where the exception ... (or one of the exceptions in the sequence ...) is not a subclass of BaseException, and
An exception is being thrown that is caught by that except ... statement.
The TypeError can be raised only when an exception is actually thrown because the names you give to except ... must be evaluated for their current values at that time; just because TypeError referenced a particular class at one point in the program's execution doesn't mean it won't be changed later to reference another object (though that would be admittedly perverse).
The Python interpreter should be giving you a full traceback of the exception; the first thing you need to do is find this. It could be occurring in one of two situations. (This is for single-threaded programs; I'm assuming your program is not multithreaded.)
During the execution of your program, in which case the program will be terminated by the exception, or
During finalization of objects (in their __del__(self) functions) in which case the error will be printed to stderr.
In both cases there should be a stack trace, not just the error message; I've confirmed that at least on Python ≥3.4 a stack trace is printed out for case 2.
You then need to follow this stack trace to see where the problem lies. Remember that the names you give to except ... are variables (even things like TypeError) that can be reassigned, so that you could conceivably be dealing with a (perverse) situation like:
TypeError = False
try:
...
except TypeError:
...
But more likely it will be something obvious such as:
class MyException: # Doesn't inherit from Exception
...
try:
...
except MyException:
...
There is one special case you need to be aware of: if you are seeing messages to stderr (case "2. During finalization," above) printed out as your program exits that means that the exception was thrown during cleanup as the interpreter shuts down, where random variables throughout the program may have already been set to None as part of the cleanup process. But in this case your program should still exit successfully.
When running Scalatest and JUnit tests in SBT I receive a short summary at the end:
Passed: Total 1359, Failed 0, Errors 0, Passed 1358, Skipped 1, Ignored 13, Pending 1
I understand the meaning of the Total count, passed and ignored tests.
But what is the meaning of:
Skipped?. It looks like Ignored but there must be some difference.
Pending?. Aren't all the tests processed when the summary is given?
Difference between Failed and Errors?
Here is an explanation:
Passed means the test has run successfully.
Ignored means the test has been tagged as ignored, probably because it needs to be fixed.
Skipped means the assume condition is not satisfied, and the test is not run. More information
Pending, the test needs to be written. More information.
Difference between failed/error: I'm not sure, but a failed test is a test that has a failed assertion (TestFailedException when using ScalaTest), whereas an error is an unexpected exception.
Total count is the sum of:
Passed
Pending
Failed
Error
I am testing a software component and want that software to throw an Exception in certain situations.
I want to reproduce these situations by using the robot framework.
The testcase shall succeed if I catch a specific Exception (which I am expecting, because I am deliberately creating an error-state in my component under test)
The testcase shall fail if I do not receive the specific Exception (i.e. my component under test did not fail(throw an exception) in an error situation)
What I am looking for is something like this:
prepareErrorInTestEnvironment
try
executeComponentWhichThrowsException
except
pass
fail
Treatment of "expected exception" are a bit specific in Robot Framework as usually exception will fail the keyword and hence the test.
The keyword you are looking for is Run Keyword and Expect Error.
Your test would look like
*** Test Cases ***
my test
prepareErrorInTestEnvironment
Run Keyword and Expect Error TheExceptionYouExpect executeComponentWhichThrowsException
This will success if you get the proper exception, and fail otherwise
I believe try/else is what you want
prepareErrorInTestEnvironment
try:
executeComponentWhichThrowsException
except:
pass
else:
fail
Also you can return on except so fail will not execute:
prepareErrorInTestEnvironment
try:
executeComponentWhichThrowsException
except:
*dosomething*
return
fail