I am writing a test automation framework, and trying to simplify life for my users as much as possible. I would like my users to just assert as regular Junit 5 test, and the log writing (my instance of Log4J), report entry (Extent Report) will all be done within the assert.
So, I would like to delegate org.junit.jupiter.api.Assertions class so that:
assertTrue(myCondition, "My Message");
Will do the following (I copied the original assertTrue and added my functionality):
package org.junit.jupiter.api;
#API(status = STABLE, since = "5.0")
public class Assertions {
//...... Some original org.junit.jupiter.api.Assertions functions
public static void assertTrue(boolean condition, String message) {
try{
AssertTrue.assertTrue(condition, message);
}
catch(AssertionError error){
//Do my things - reporter and logger
throw error;
}
}
//...... Some original org.junit.jupiter.api.Assertions functions
}
However
org.junit.jupiter.api.Assertions is a long class to delegate.
it becomes complicated since AssertTrue is only visible in package level.
Would like to get some fresh thoughts on how to resolve it elegantly....
Thanks,
OK,
What I ended up doing was creating a new DelegatingAssert class, and for every Assert I was interested, I created the following:
public static void assertFalse(DelegatingExtentTest testCase, boolean condition, String message) {
try{
Assertions.assertFalse(condition);
testCase.pass(message);
}
catch(AssertionError e) {
testCase.fail("Did not: " + message);
getLogger().error("Fail message: " + e.getMessage());
getLogger().error("Fail stack trace: " + Helper.getStackTrace(e));
throw e;
}
}
Related
Let's say I test a class method that is reliant on another method that we do not want or can not test directly, which handles a checked exception, in the following manner:
public class A {
public void process(){
if (isProcessingSuccessful()){
LOG.info("Success");
}
else {
LOG.error("Fail");
}
}
private boolean isProcessingSuccessful(){
try{
doSomeOtherStuff();
return true;
}
catch (Exception e){
return false;
}
}
}
Now, if I have a test class testing for the A#process(), like:
#Test
public void shouldFailDueToCommandGatewayError() {
A a = new A();
// setting up preconditions
//testing here
a.process();
//Now, assert exception was thrown during the course of a.process() execution, something like
exception.expect(NullPointerException.class);
// ?? how to do that?
}
TLTD: It is possible to write separate test for isProcessingSuccessful() or do something similar, but let's say that method is not accessible for testing, like it's private in a library?
Given the above constraints, is there any way to write a test in a way that ascertains the exception was thrown in the underlying method as above?
No, junit can't tell the exception was thrown, since it gets eaten by the code being tested. For you to detect what happened here you would have to check what was written to the log. Replace the appender with something that holds onto what is written to it, then the test can verify what was written to it at the end of the test.
You can't catch the exception again which have been already consumed. The only way is to catch the exception with the test method as described below.
Annote the test method that is supposed to fail with #Test and use the expected parameter for the expected exception.
#Test(expected = NullPointerException.class)
public void shouldFailDueToCommandGatewayError() {
// something that throws NullPointerException
}
#Test(expected = NullPointerException.class)
This basically says:
If this test quits with a NullPointerException then everything is as expected. Otherwise this test will fail.
#Test(expected = NullPointerException.class)
has been mentioned already. This feature came wuth JUnit 4. Before that and if you want to do want to check more than just a particular type of exception being thrown, you can do something like this:
try {
doSometing("", "");
fail("exception expected");
}
catch(IllegalArgumentException iae) {
assertEquals("check message", "parameter a must not be empty", iae.getMessage());
assertNull("check non-existance of cause", iae.getCause());
}
try {
doSometing("someval", "");
fail("exception expected");
}
catch(IllegalArgumentException iae) {
assertEquals("check message", "parameter b must not be empty", iae.getMessage());
assertNull("check non-existance of cause", iae.getCause());
}
This is particular useful if the same type of exception is thrown and you want to ensure that the "correct" exception is thrown with a given combination of parameters.
In Selenium, if a step fails for a test case, is it possible to just report the failure and continue with remaining steps? Currently the execution halts if there is an exception. This is what my Test case looks like-
public class TC002_abc extends OpentapWrappers
{
#Test (description="Test")
public void main()
{
try
{
WebDriverWait wait=new WebDriverWait(driver, 60);
VerifyTitle(Constant.HomePage_Title);
Click(HomePage.link_Login(driver), "Login Link");
wait.until(ExpectedConditions.urlContains(Constant.LoginURL));
VerifyTextPopulated(CommunicationPref.lbl_EmailAddress_Input(driver), Constant.EmailAddress);
/* Validate Email Communications */
Click(CommunicationPref.link_EditEmailCommunications(driver),"Edit Email Communications");
VerifyText(CommunicationPref.lbl_UnCheckedEmailCommunications(driver), Constant.UnCheckedEmailCommunications_Text);
Click(CommunicationPref.btn_EmailCommunicationsSave(driver), "Save");
VerifyText(CommunicationPref.lbl_CheckedEmailCommunications(driver), Constant.CheckedEmailCommunications_Text);
}
catch (NoSuchElementException e)
{
e.printStackTrace();
Reporter.reportStep("NoSuchElementException" , "FAIL");
}
}
#BeforeClass
public void beforeClass()
{
browserName="firefox";
testCaseName = "TC002_abc";
testDescription = "Test";
}
}
Sample Method-
public static void VerifyTitle(String title){
try
{
if (driver.getTitle().equalsIgnoreCase(title))
{
Reporter.reportStep("Page is successfully loaded :"+title, "PASS");
}
else
Reporter.reportStep("Page Title :"+driver.getTitle()+" did not match with :"+title, "FAIL");
}
catch (Exception e)
{
e.printStackTrace();
Reporter.reportStep("The title did not match", "FAIL");
}
}
Since you're using TestNG, implement a Soft Assertion
public void VerifyTitle(String title)
{
SoftAssert assertion = new SoftAssert();
String returnedTitle = driver.getTitle();
if (assertion.assertTrue(returnedTitle.contains(title)))
{
Reporter.reportStep("Page is successfully loaded :" + title, "PASS");
} else
{
Reporter.reportStep("Page Title :" + driver.getTitle() + " did not match with :" + title, "FAIL");
}
}
Let me know if this helps.
if a step fails for a test case, is it possible to just report the
failure and continue with remaining steps?
Short answer: YES
Long answer: YES
Selenium is framework built on top of a test engine such as JUnit or TestNG. On those engines, if you do nothing, the tool will interpret as a pass. In other words, in the absence of an assertion, the engines will assume the test passed. Since Selenium is built on top of this, the same can be said about Selenium. The code snippet below is a representation of what a Cucumber step looks like.
#When("my test step here")
public void myTestStep(...) {
boolean result = false;
try {
result = myTest(...);
}
} catch (Exception e) {
// log your exception (don't rethrow)
}
if (result) {
// log your passing test
} else {
// log your failing test
Assert.fail(); // This is what prevents subsequent steps to be executed. Remove it, and you should be able to continue to test.
}
For a JUnit or TestNG style method is basically the same. You may have an #AfterClass or #AfterTest hook that might handle telling the test framework to pass of fail test. TYPICALLY, passing assertions are implied (by not doing anything - i.e. executing an empty method). However, failing assertions are EXPLICIT and must be included somewhere. Just look for those Assert.fail() methods and remove them. A better alternative is to add a configurable property to your test suite that will turn this on or off.
} else {
// log your failing test
if (skip_off) {
Assert.fail(); // This is what prevents subsequent steps to be executed. Remove it, and you should be able to continue to test.
}
}
In this context, skip_off is the value of Boolean property you might have stored in a configuration file that when set to true, it will skip enforcing fail assertions.
I'm writing a custom sonar rule for java using java. I encountered an assertion error which can not be fixed easily. I'm sure that the source code is correct. But the test case can not be passed. I wonder what should I care about when using TDD process and how can I fix it.
public class logTCheckFile {
private static Logger logger = Logger.getLogger(logTCheckFile.class);
public void loggingWithID(String nonsense) throws myException{
logger.error("errorID:20160801 this is an error");
return;
}
public void loggingWithoutID(String nonsens){
try{
logger.error("this is an error");
}catch(NullPointerException e){
logger.error("what",e);
}
return;
}
public void specific(){
logger.error("only the logger");
try{
logger.error("this is an error");
}catch(NullPointerException e){
logger.error("without an exception");
}
return;
}
}
I'm testing the file above, I wrote a rule to test whether the exception, which is not thrown, is printed in the logger.
The message is AssertionError: Unexpected at [20](here is a picture of the failure stack trace)
The code I wrote to check the file is as follows:
public class logTCheck extends IssuableSubscriptionVisitor {
Logger log = Logger.getLogger(logTCheck.class);
#Override
public List<Kind> nodesToVisit() {
return ImmutableList.of(Kind.METHOD);
}
#Override
public void visitNode(Tree tree){
MethodTree method = (MethodTree) tree;
if(method.throwsClauses().size()==0){
log.info("this method does not have a throw clause");
BlockTree bt = method.block();
for(StatementTree st:bt.body()){
if(st.is(Kind.TRY_STATEMENT)){
TryStatementTree tst = (TryStatementTree) st;
for(CatchTree ct:tst.catches()){
for(StatementTree state:ct.block().body()){
ExpressionStatementTree ex = (ExpressionStatementTree)state;
MethodInvocationTree mit = (MethodInvocationTree) ex.expression();
if(mit.arguments().size()!=2){
log.error(method.simpleName());
reportIssue(method.simpleName(), "you didn't print the exception in the log");
}
}
}
}
}
};
}
}
The message is AssertionError: Unexpected at [20]
This means that line 20 of the test data contains a violation of the rule you are checking.
You need to tell the validator that this violation is intentionally there.
An easy way to do this is to add a comment like this on the line right before the violation:
// Noncompliant#+1 {{the violation message}}
The #+1 means that the violation is on the next line.
Adjust the number appropriately.
The comment must be at the beginning of the line,
or there may be whitespace in front of the //.
The violation message enclosed within {{...}} is optional, but highly recommended.
When doing TDD,
an easy way to enter the correct message is to add something like {{x}} which will cause the test to fail,
and then you can copy the message from the test output into the test file to fix it.
I finally found the problem from another answer from Michael. I didn't tell the tester where the issue should be. I should use the comment// Noncompliant to mark out the issue.
I have a java program which throws an exception with 2 different messages for 2 different scenarios and I want the Junit test case to check for equality for both of these messages. As an example -
public void amethod() {
// do some processing
if(scenario1 == true) {
throw new MySystemException("An error occured due to case 1 being incorrect.");
}
else if(scenario2 == true) {
throw new MySystemException("An error occured as case 2 could not be found");
}
}
Now the JUnit for this would be something like-
public void testAMethod() {
// do something
assertEquals("Expected", "Actual");
}
As I understand, in this above example, if I use the Scenario1 exception message the junit will fail when an exception is thrown for Scenario2 and vice versa.
I would like to know if there is any other way provided in Junit by which I can use this one test method and check for both the messages for the test to pass?
Something like an OR, if possible to provide the "Expected" value with both these expected message.
I hope my query is clear enough.
Thanks
UPDATE
Sorry for the delayed response, had got caught up with some other urgent matter.
Thank you all for the very nice suggestions, it certainly has helped me to understand a bit better now.
Eventually, to keep it rather simple I decided to implement a somewhat similar solution suggested by Don Roby. So created a new test class which looks like -
public void testAMethodScenario1() {
// do the necessary
assertEquals("Expected Exception Message 1", "Actual");
}
public void testAMethodScenario2() {
// do the necessary
assertEquals("Expected Exception Message 2", "Actual");
}
Thank you all again for your responses.
I think you need to manually catch the exception (for each scenario) and individually check the message:
try {
// trigger scenario 1
fail("An exception should have been thrown here !");
} catch (MySystemException e1) {
assertEquals("Wrong error message", m1, e1.getMessage());
}
try {
// trigger scenario 2
fail("An exception should have been thrown here !");
} catch (MySystemException e2) {
assertEquals("Wrong error message", m2, e2.getMessage());
}
Of course, you can have these scenarios defined as enum constants and simply iterate through them and check each of them within a loop, since the "copy/paste design pattern" is pretty obvious in the above code. :)
You seem to be asking two things here, how to test an exception and how to assert that a value matches either of two possible expected values.
To test for an exception, you can either use a JUnit4 annotation:
#Test(expected=MySystemException.class)
public void testException() {
amethod();
}
or use a try-catch in your test:
#Test
public void testException() {
try {
amethod();
fail("MySystemException expected");
}
catch (MySystemException e) {
// Success!
}
}
And if you have only one message, in the try-catch version you can assert that you got it with an AssertEquals in the catch block.
The best testing would have separate tests for your two scenarios, and expect the correct single message. Better code might in fact have distinct exceptions for the two situations.
But the need for a more complex assertion than simple equality does come up anyway, and there's an elegant solution for it in Hamcrest matchers.
Using that for this situation, you could write something like (untested - don't trust my syntax completely):
#Test
public void testException() {
try {
amethod();
fail("MySystemException expected");
}
catch (MySystemException e) {
String expectedMessage1 = "An error occured due to case 1 being incorrect.";
String expectedMessage2 = "An error occured as case 2 could not be found";
assertThat(e.getMessage(),
anyOf(equalTo(expectedMessage1), equalTo(expectedMessage2)));
}
}
Can you predict which scenario will occur? If so, Costi's answer is correct. If not, because there's some randomness or whatever, you can write:
#Test
public void testAmethodThrowsException() {
try {
amethod();
fail("amethod() should have thrown an exception");
}
catch (MySystemException e) {
String msg = e.getMessage();
assertTrue("bad message: " + msg, msg.equals("An error occured due to case 1 being incorrect.") || msg.equals("An error occured as case 2 could not be found"));
}
}
The declared types of exception thrown bya method are part of its API. If you really want to distinguish different failure modes, you should declare a different exception type for each failure mode.
So, something like this:
/**
* Do something.
* #throws MySystemException1 in case 1.
* #throws MySystemException2 if Foo not found.
*/
public void amethod() {
// do some processing
if(scenario1 == true) {
throw new MySystemException1("Case 1.");
}
else if(scenario2 == true) {
throw new MySystemException2("Foo not found");
}
}
#Rule solution in JUnit4:
public class ExceptionRule implements MethodRule {
#Override
public Statement apply(final Statement base, final FrameworkMethod method, Object target) {
return new Statement() {
#Override
public void evaluate() throws Throwable {
try {
base.evaluate();
Assert.fail();
} catch (MySystemException e) {
if(scenario1)
assertEquals("Expected error message1", e1.getMessage();
if(scenario2)
assertEquals("Expected error message2",e1.getMessage();
}
}
};
}
}
In your testcase, use the Rule:
#Rule public ExceptionRule rule = new ExceptionRule();
JUnit 4 provides (Expected Exception.class)
#Test(expected= MySystemException.class) public void empty() {
// what ever you want
}
Google: Expected Exceptions JUnit for more info.
BDD Style Solution with Catch Exception
#Test
public void testAMethodScenario1() {
//given scenario 1
when(foo).amethod();
then(caughtException())
.isInstanceOf(MySystemException.class)
.hasMessage("An error occured due to case 1 being incorrect.");
}
#Test
public void testAMethodScenario2() {
//given scenario 2
when(foo).amethod();
then(caughtException())
.isInstanceOf(MySystemException.class)
.hasMessage("An error occured as case 2 could not be found");
}
Source code
https://gist.github.com/mariuszs/7490875
Dependencies
com.googlecode.catch-exception:catch-exception:1.2.0
A better solution with #Rule, you can assert both exception and expection message as well.
#Rule
public ExpectedException expectedException = ExpectedException.none();
#Test
public void aMethod_Scenario1True_ThrowsException() {
expectedException.expect(MySystemException.class);
expectedExcepion.expectMessage("An error occured due to case 1 being incorrect.");
//when().thenReturn();
//handle the repositories, static methods and other sub methods, if needed
amethod();
}
#Rule is the more elegant way to write the exception.
I have written a few JUnit tests with #Test annotation. If my test method throws a checked exception and if I want to assert the message along with the exception, is there a way to do so with JUnit #Test annotation? AFAIK, JUnit 4.7 doesn't provide this feature but does any future versions provide it? I know in .NET you can assert the message and the exception class. Looking for similar feature in the Java world.
This is what I want:
#Test (expected = RuntimeException.class, message = "Employee ID is null")
public void shouldThrowRuntimeExceptionWhenEmployeeIDisNull() {}
You could use the #Rule annotation with ExpectedException, like this:
#Rule
public ExpectedException expectedEx = ExpectedException.none();
#Test
public void shouldThrowRuntimeExceptionWhenEmployeeIDisNull() throws Exception {
expectedEx.expect(RuntimeException.class);
expectedEx.expectMessage("Employee ID is null");
// do something that should throw the exception...
System.out.println("=======Starting Exception process=======");
throw new NullPointerException("Employee ID is null");
}
Note that the example in the ExpectedException docs is (currently) wrong - there's no public constructor, so you have to use ExpectedException.none().
In JUnit 4.13 you can do:
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertThrows;
...
#Test
void exceptionTesting() {
IllegalArgumentException exception = assertThrows(
IllegalArgumentException.class,
() -> { throw new IllegalArgumentException("a message"); }
);
assertEquals("a message", exception.getMessage());
}
This also works in JUnit 5 but with different imports:
import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
...
I like the #Rule answer. However, if for some reason you don't want to use rules. There is a third option.
#Test (expected = RuntimeException.class)
public void myTestMethod()
{
try
{
//Run exception throwing operation here
}
catch(RuntimeException re)
{
String message = "Employee ID is null";
assertEquals(message, re.getMessage());
throw re;
}
fail("Employee Id Null exception did not throw!");
}
Do you have to use #Test(expected=SomeException.class)? When we have to assert the actual message of the exception, this is what we do.
#Test
public void myTestMethod()
{
try
{
final Integer employeeId = null;
new Employee(employeeId);
fail("Should have thrown SomeException but did not!");
}
catch( final SomeException e )
{
final String msg = "Employee ID is null";
assertEquals(msg, e.getMessage());
}
}
Actually, the best usage is with try/catch. Why? Because you can control the place where you expect the exception.
Consider this example:
#Test (expected = RuntimeException.class)
public void someTest() {
// test preparation
// actual test
}
What if one day the code is modified and test preparation will throw a RuntimeException? In that case actual test is not even tested and even if it doesn't throw any exception the test will pass.
That is why it is much better to use try/catch than to rely on the annotation.
I never liked the way of asserting exceptions with Junit. If I use the "expected" in the annotation, seems from my point of view we're violating the "given, when, then" pattern because the "then" is placed at the top of the test definition.
Also, if we use "#Rule", we have to deal with so much boilerplate code. So, if you can install new libraries for your tests, I'd suggest to have a look to the AssertJ (that library now comes with SpringBoot)
Then a test which is not violating the "given/when/then" principles, and it is done using AssertJ to verify:
1 - The exception is what we're expecting.
2 - It has also an expected message
Will look like this:
#Test
void should_throwIllegalUse_when_idNotGiven() {
//when
final Throwable raisedException = catchThrowable(() -> getUserDAO.byId(null));
//then
assertThat(raisedException).isInstanceOf(IllegalArgumentException.class)
.hasMessageContaining("Id to fetch is mandatory");
}
Raystorm had a good answer. I'm not a big fan of Rules either. I do something similar, except that I create the following utility class to help readability and usability, which is one of the big plus'es of annotations in the first place.
Add this utility class:
import org.junit.Assert;
public abstract class ExpectedRuntimeExceptionAsserter {
private String expectedExceptionMessage;
public ExpectedRuntimeExceptionAsserter(String expectedExceptionMessage) {
this.expectedExceptionMessage = expectedExceptionMessage;
}
public final void run(){
try{
expectException();
Assert.fail(String.format("Expected a RuntimeException '%s'", expectedExceptionMessage));
} catch (RuntimeException e){
Assert.assertEquals("RuntimeException caught, but unexpected message", expectedExceptionMessage, e.getMessage());
}
}
protected abstract void expectException();
}
Then for my unit test, all I need is this code:
#Test
public void verifyAnonymousUserCantAccessPrivilegedResourceTest(){
new ExpectedRuntimeExceptionAsserter("anonymous user can't access privileged resource"){
#Override
protected void expectException() {
throw new RuntimeException("anonymous user can't access privileged resource");
}
}.run(); //passes test; expected exception is caught, and this #Test returns normally as "Passed"
}
If using #Rule, the exception set is applied to all the test methods in the Test class.
I would prefer AssertJ for this.
assertThatExceptionOfType(ExpectedException.class)
.isThrownBy(() -> {
// method call
}).withMessage("My message");
I like user64141's answer but found that it could be more generalized. Here's my take:
public abstract class ExpectedThrowableAsserter implements Runnable {
private final Class<? extends Throwable> throwableClass;
private final String expectedExceptionMessage;
protected ExpectedThrowableAsserter(Class<? extends Throwable> throwableClass, String expectedExceptionMessage) {
this.throwableClass = throwableClass;
this.expectedExceptionMessage = expectedExceptionMessage;
}
public final void run() {
try {
expectException();
} catch (Throwable e) {
assertTrue(String.format("Caught unexpected %s", e.getClass().getSimpleName()), throwableClass.isInstance(e));
assertEquals(String.format("%s caught, but unexpected message", throwableClass.getSimpleName()), expectedExceptionMessage, e.getMessage());
return;
}
fail(String.format("Expected %s, but no exception was thrown.", throwableClass.getSimpleName()));
}
protected abstract void expectException();
}
Note that leaving the "fail" statement within the try block causes the related assertion exception to be caught; using return within the catch statement prevents this.
Import the catch-exception library, and use that. It's much cleaner than the ExpectedException rule or a try-catch.
Example form their docs:
import static com.googlecode.catchexception.CatchException.*;
import static com.googlecode.catchexception.apis.CatchExceptionHamcrestMatchers.*;
// given: an empty list
List myList = new ArrayList();
// when: we try to get the first element of the list
catchException(myList).get(1);
// then: we expect an IndexOutOfBoundsException with message "Index: 1, Size: 0"
assertThat(caughtException(),
allOf(
instanceOf(IndexOutOfBoundsException.class),
hasMessage("Index: 1, Size: 0"),
hasNoCause()
)
);
#Test (expectedExceptions = ValidationException.class, expectedExceptionsMessageRegExp = "This is not allowed")
public void testInvalidValidation() throws Exception{
//test code
}