This question already has answers here:
Conditionally ignoring tests in JUnit 4
(5 answers)
Closed 8 years ago.
It can be happened, that the the unit test cannot test properly due too system condition.
eg: another job is running, what locks a table what is used by a service what should be tested.
in this case the output of the test should not be SUCCESS nor FAIL...
it should be just like IGNORED
is there a way to set the unit test 'ignored' in the test itself?
It looks like you want Assume from JUnit4. Look at this documentation http://junit.sourceforge.net/javadoc/org/junit/Assume.html
Related
This question already has answers here:
Mocking static methods with Mockito
(19 answers)
Closed 4 years ago.
I'm trying to test a function that's making a Stripe api call Plan.retrieve("my_plan_id"). I'm using junit as my testing library and mockito as my mocking library. The problem here is that Plan.retrieve() is a static method, and mockito doesn't support mocking static methods.
I've tried mocking out the Plan class like so.
Plan plan = new Plan();
plan.setId("my_plan_id");
Plan mockedPlan = mock(Plan.class);
when(mockedPlan.retrieve("my_plan_id")).thenReturn(plan);
assertEquals(plan.getId(), myTestedFunction().getId());
This just results in an Stripe Authentication exception because I never gave Stripe an API Key.
What is the correct implementation for mocking Stripe api calls for testing in java? I can't seem to find any information on this.
Update
I was already aware of PowerMock, I was looking for a solution that involved using Mockito. Dawood ibn Kareem has pretty much answered my question. If I could mark that as the accepted answer I would. I admit that it was a pretty obvious answer, but for some reason it just didn't occur to me.
I also don't understand why people are downvoting my question, was it a bad question?
Mockito has no support for mocking static methods, you can use PowerMock to achieve the task. Specifically you should be looking at: https://github.com/powermock/powermock/wiki/Mockito#mocking-static-method
A similar question has been answered in this thread: Mocking static methods with Mockito
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am new to Mockito and I have started to learn it. But I have some questions. Why do we need to use Mockito? As far as I know it is used to Mock(Create dummy object) and write the test cases before having actual running code. But, what if I want to test my already implemented code to check whether they are functioning properly or not. How would I test it using Mockito?
For instance, I have CRUD methods and I would like to test whether Create is functioning properly by actually inserting data in database using my Create method, similarly for others. Can we attain it using Mockito. If not, then do I need to write different testcases for them without using Mockito?
The Mock is used to each class or service you are using. The class under test should not be Mocked. Lets assume you are connecting to a remote service which is being built by one of your engineering team, and you are not familiar with its internal functionality but you know what requests and response it returns.
In that case, you can create a Mock of that Object, and defines it with set of responses returns in different situations. Each situation should get its own different test and for each response you should check separately the reaction of the code (you are working on).
Another great example is creating a limitation checks. Lets think of exception that might be thrown in some situations.
You can Mock the object that will throw the Exception which is simple(~2-3 line of test code if you are using Mock) and you can check how the code you have written reacts to that Exception. Without the Mock the throwing of an exception might be really complicated thing and not so easy to use if you are not familiar with the small details. And of course the Mock enables you to be on focus of the main functionality you are checking cause it make the checking time very very small. And that is a bless when time to market is a critical thing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
public class JUnitTimeout {
#Test(timeout = 100)
public void infinity() {
//Some code to test
}
}
what are the performance factors you need to consider to give a particular timeout value for a junit test case.
for example #Test(timeout = 100) how can you give a value for the timeout in here it is 100
I would not use timeout for regular unit tests. These tests run on different computers, with different OS's, and different amount of other processes running. Which in turn will make a small "hickup" fail your tests, and in many cases also your build (ant, maven). Setting a timeout close to what calling the method usually takes will only become a nuisance, halting a build seemingly at random.
What timeout could be used for is integration tests, that don't run at each build. For instance, if one has a non-functional requirement stating that a webservice should have no more than 2 seconds response time, a test with a timeout of 2 seconds that calls the actual webservice could be run before deployment of a new version, to make sure that the requirement is not broken.
Edit: Actually, I found a reason to use timeout on regular unit tests. I noticed some tests in my build taking a lot of time, turned out to be tests of what happened when a SOAP-client couldn't connect, and it was tested by trying to call an invalid URL. The problem is that there is a 20 second timeout, so each build got took a minute extra for three tests. I solved it through creating a MethodRule through, so the timeout can be added once for each class, rather than in each test-method. So, identifying tests that would slow down the build substantially is a use case for this. I'll set the timeout to 3-5 seconds, anything above this is probably taking an unecessary amount of time, and will be likely to slow down the build.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Should I write unit-test for every public method? For example I have a CRUD service, so I have
create, read, update, delete methods. But when I write test to delete or update methods, I implicitly test read and create methods (for example to test the update method first I need create an entity(create), then retrieve it (read), then update it and then retrieve it again to ensure it changed).
I would write tests for get and create, yes:
It makes it easier to separate behaviour you're deliberately testing from behaviour you're incidentally testing
It makes it easier to test failure conditions and other scenarios that aren't covered by your other methods
It means if you change your implementation of delete / update to not use get / create, you're still testing get / create
Ideally, I'd attempt (without getting too hung up about it) to make the tests set and check the data at the "lower" level - e.g. performing direct in-memory database access. That way you're really testing "If I create an entity, the data in the database looks like {this}" (and likewise when fetching). Just being able to create and then get the same results again is fine in terms of black box testing, but I typically think of unit tests as more white box.
Should I write unit-test for every public method? Yes
Writing a test case for each public method is best thing. To test delete operation you should call create test first and then call delete test method. This way your delete test method will be independent and you can test all possible scenrio.
This question already has answers here:
Finding the current persistence unit for the current EntityManagerFactory
(2 answers)
Closed 8 years ago.
How do you get the name of a persistence-unit in Java? I have a persistence.xml with many units, so I want to control which unit is used to create my EntityManager.
There's method like getPersistenceName or smth? I have searched for a while but did not find anything useful.
Please check this thread:
Finding the current persistence unit for the current EntityManagerFactory