I've got the following test which I have put a try catch around so it fails if actual value does not equal expected value:
try{
Assert.assertEquals(ExpectedCount, ActualCount);
}catch (Throwable t){
System.out.println ("Actual value is not equal to expected value");
}
Whenever I run this test it passes. However if expected=actual no message is printed, which is correct. If they are not equal then the message i printed. So the test logic is valid.
However the Juint test still passes.
I have been trying the incorporate the following but cannot get it to work:
(Added this at public level in the class of the test)
#Rule
Public ErrorCollected errCollector = new ErrorCollector();
Added:
errCollector.addError(t);
Under
System.out.println ("Actual value is not equal to expected value");
I am getting the error back "Rule cannot be resolved to a type" It does not give me any option to import.
I've been trying to find out how use the #Rule method to make the test to fail, but cannot figure it out.
As #oers says, the reason you can't find Rule is probably because your version of JUnit is too old. Try a later version, > 4.7.
The easiest solution to your problem is just to rethrow the exception that you're catching:
try {
Assert.assertEquals(ExpectedCount, ActualCount);
} catch (Throwable t) {
System.out.println ("Actual value is not equal to expected value");
throw t;
}
but you'll need to add throws Throwable to your test method. You have another alternative, to add a description to your assert:
Assert.assertEquals("Actual value is not equal to expected value", ExpectedCount, ActualCount);
Related
Scenario: Below negative scenario to be tested during Integration test. currently the test case getting failed due exit and not reaching to the test method.
example :
private void method1(int a){
try{
if(a == 0){
throw exception();
}else{
---
}
}catch(exceptionclass e){
System.exit(1);
}
}
Sound like a bad smell to me that calling a method on a object can cause JVM to exist. Normally it should be done in the main method.
So I would refactor your codes such that your testing object will throw a kind of Exception to indicate that some kind of fatal error happens such that the main method can catch it and terminate the JVM.
Then you can simply test that if it will throw this Exception from your test case.
In my framework - , Test & PageObjModel classes are there. incase any method is not executed because of wrong xpath or other any issue the Test is terminating but in the Report-Console it is showing all the Testcase are PASS.
Any issue in the Action methods of PageObjModel, some times it will skip that particular line of code and continue execution. sometimes entire test is terminating. in both the case Report-Console it is showing all the Testcase are PASS i.e No failures of Testcases.
Please have a look into below example of code and suggest me to fail the TC incase of failures.
I tried to include Assert.fail(), Assert.true(fail) in the "catch" block, though it is showing PASS results.
PageObjModel:
class A{
// list of xpaths
public static fibal String Login_xpath = "//*[#id='login'];
public void login(){
try{
// All Action methods are define here
}catch (Exception e){
e.printStackTrace();
//Assert.assertTrue(false);
Assert.fail();
} } }
Test class:
#Test
public void loginTest(){
//calling methods
xx.login();
}
This is just sample code. please help me where can I put Assertions to fail the TC when failure occurs in the code
If we are using try-catch in your code, please add throw as well. otherwise, it won't inform testng about the failure.
catch (AssertionError e) {
e.printStackTrace();
takeSnapShot(action);
throw e;
}
I want to check error messages. These error messages appear only when my website encounters a problem.
My problem is that I use findElement in order to check the error message. So when something goes wrong, Selenium finds it, and everything is O.K.
But when it doesn't (meaning - my website is O.K with no problems) - then Selenium indicates that it doesn't find the element, and rises an exception.
Any idea?
you can surround the findElement in a try-catch block, which will do nothing if the element is not found. e.g.
private boolean isElementPresent(By by) {
try {
driver.findElement(by);
return true;
} catch (NoSuchElementException e) {
return false;
//or do nothing
}
}
Take a look at the answer Selenium Webdriver NoSuchElementException
It suggests the following (I've adapted it a bit for your needs) :
List<WebElement> errorElements = driver.findElements(By.id("ERROR_ID"));
if (!errorElements.empty()) {
// Tests your errors
}
1.For this you should design your test case in such a way that you writes code to check error message only when you are sure that you will get error message.
2.But the point is why are you checking for error message when you know that there will be no problem and code will run fine.
3.If you doesn't know that error will occur.. You can place the risky code in try block and write a catch block which will find error message and check it.
I have a few NUnit tests that run Selenium.
There are some prerequisite to some tests. An example for this would be logging in to our website.
We use a standard test user for test A, but if that user doesn't exist for whatever reason, we'll get a test failure with nothing useful (Selenium will just report it couldn't find the element at line 50). So I planned to check for the user's existence before we try to run the test - in the TextFixtureSetUp method.
I have a check to ensure the user exists, and if not, throw a helpful error message.
For example:
[TestFixtureSetUp]
public void SetUp()
{
bool userExists = userManager.GetUserByEmailAddress("someuser#fish.com") != null;
if (!userExists)
{
throw new Exception("Test user someuser#fish.com doesn't exist.");
}
}
vs
[TestFixtureSetUp]
public void SetUp()
{
bool userExists = userManager.GetUserByEmailAddress("someuser#fish.com") != null;
if (!userExists)
{
Assert.Fail("Test user someuser#fish.com doesn't exist.");
}
}
My question is this a good idea? Should I throw an exception or use Assert.Fail()? Am I thinking about this in the wrong way, or is it something doesn't matter really.
Reason to throw exception - you can catch it later on and try to use another user.
Reason to fail asserrt - when user is not found, it means end to the testmodel.
If you go the exception way - think about GetUserByEmailAddress will be throwing it if it does not find the right user...
Instead of Assert.Fail() raising AssertionException, I would rather use Assert.Inconclusive() or better Assume.That(userManager.GetUserByEmailAddress("someuser#fish.com"), Is.Not.Null) to raise InconclusiveException in this case.
You may want to watch it here: https://docs.nunit.org/articles/nunit/writing-tests/Assumptions.html
In below code I want to neutralize the throw and continue the method - Can it be done ?
public class TestChild extends TestParent{
private String s;
public void doit(String arg) throws Exception {
if(arg == null) {
Exception e = new Exception("exception");
throw e;
}
s=arg;
}
}
The net result should be that, in case of the exception triggered (arg == null)
throw e is replaced by Log(e)
s=arg is executed
Thanks
PS : I can 'swallow' the exception or replace it with another exception but in all cases the method does not continue, all my interventions take place when the harm is done (ie the exception has been thrown)
I strongly doubt that general solution exists. But for your particular code and requirements 1 and 2:
privileged public aspect SkipNullBlockAspect {
public pointcut needSkip(TestChild t1, String a1): execution(void TestChild.doit(String))
&& this(t1) && args(a1) ;
void around(TestChild t1, String a1): needSkip(t1, a1){
if(a1==null) //if argument is null - doing hack.
{
a1=""; //alter argument to skip if block.
proceed(t1, a1);
t1.s=null;
a1=null; //restore argument
System.out.println("Little hack.");
}
else
proceed(t1, a1);
}
}
I think that generally what you want makes no sense most cases because if an application throws an exception it has a reason to do so, and that reason almost always includes the intention not to continue with the normal control flow of the method where the exception was thrown due to possible subsequent errors caused by bogus data. For example, what if you could neutralise the throw in your code and the next lines of code would do something like this:
if(arg == null)
throw new Exception("exception");
// We magically neutralise the exception and are here with arg == null
arg.someMethod(); // NullPointerException
double x = 11.0 / Integer.parseInt(arg); // NumberFormatException
anotherMethod(arg); // might throw exception if arg == null
Do you get my point? You take incalculable risks by continuing control flow here, assuming you can at all. Now what are the alternatives?
Let us assume you know exactly that a value of null does not do any harm here. Then why not just catch the exception with an after() throwing advice?
Or if null is harmful and you know about it, why not intercept method execution and overwrite the parameter so as to avoid the exception to begin with?
Speculatively assuming that the method content is a black box to you and you are trying to do some hacky things here, you can use an around() advice and from there call proceed() multiple times with different argument values (e.g. some authentication token or password) until the called method does not throw an exception anymore.
As you see, there are many ways to solve your practical problem depending on what exactly the problem is and what you want to achieve.
Having said all this, now let us return to your initial technical question of not catching, but actually neutralising an exception, i.e. somehow avoiding its being thrown at all. Because the AspectJ language does not contain technical means to do what you want (thank God!), you can look at other tools which can manipulate Java class files in a more low-level fashion. I have never used them productively, but I am pretty sure that you can do what you want using BCEL or Javassist.