I wish to know how can I mock kotlin final class with PowerMock so I can test it. I followed guide for testing Java final classes but I still got this error
Cannot subclass final class
Is there any way to do that?
With Mockito 2.1.0+ you can mock final classess as well. This feature is optional, so you have to enable it by adding Mockito extension.
To do this:
Create a file named org.mockito.plugins.MockMaker and place it under the resources/mockito-extensions directory in your test folder.
The file contains a single line: mock-maker-inline
You can find more information in Mockito documentation.
Just create interfaces for your classes. Than you can simply mock your classes using interface.
Related
I have a __mocks__ folder that mocks out a node module. This works for most of my tests, but in one particular test I need a custom mock. I need my unit-tested code to ignore the mock in the __mocks__ folder, and use a specific mock that I define in the test file.
I tried using jest.unmock(), however this prevents me from defining specific mocks in my unit test (thing.test.js). If I then add some mocks or modify the module I'm mocking, the changes don't get added to the code I'm testing (thing.js).
Example:
thing.js imports AWS.js module
__mocks__/AWS.js contains AWS.js module mock
other tests use __mocks__/AWS.js
thing.test.js wants to create a custom mock that doesn't get overwritten by __mocks__/AWS.js and doesn't affect other tests -> how to do this??
I am using Typescript, but the same approach applies. I create my normal test files (thing.spec.ts) which tests the code. In our code base, we do basic tests in this file, and would use it to test non-mocked functions, and simply spyOn() calls.
We then create a separate test file (thing.mock.spec.ts) where the 'mock' indicates that the tests in the this file, are going to be using the __mock__ directory class instead. The naming is just our internal standard to be clear of what we are using.
In the thing.mock.spec.ts we do the mock of the complete class as you are doing in your test. This test file only tests functions that require the mock data, since the main tests have been done independently in the thing.spec.ts.
This would then have:
__mocks__/AWS.js
thing.js
thing.test.js
thing.mock.test.js
This way, when looking at just the file names, you get a sense of what is being used during the testing.
Im trying to get familiar with using MOQ and mocking in general. So I want to test an api controller which uses an assembly which serves as a repository for getting/updating data etc.
eg a structure like this.
HomeController
Index
Repository.GetSomeData (returns JSON object)
This repository class has an interface, and that is what is injected via the .net core startup class. The method in this case, GetSomeData does a number of steps via calls to the Db, as well as reading a file from the file system, parsing it and moving it off to another folder.
Question: How can a "mocked" Repository work without doing the things that the "real" object does? All the examples I see are simple addition, returning strings etc.
When you mock something like your repository, you going to stub out methods on the repository to return some canned result. Calls to those methods on the repository mock, then, bypass the real methods and instead just do what you've stubbed.
Essentially, you need to first identity what methods will be utilized. Then, you should determined appropriate responses those methods should return based on the particular scenario you're attempting to unit test. Then, you create the mock and add stubs for those methods with those responses.
The whole point of mocking is to remove variables, so you're intentionally trying to get to the "happy path": the set of internal responses that put the action in the state you need it to be in for specific test you're conducting.
I would like to use the features of both Arquillian and PowerMock in the same JUnit 4 test.
The problem is that both products are JUnit Runners which should be used with #RunWith, and this is not possible to use multiple #RunWith on the same test class, or to put multiple Runners class in the same #RunWith annotation.
Do you know any way to do that ?
You can use PowerMock without using the runner if you use the PowerMockRule (which is a TestRule). From the PowerMockRule:
Since version 1.4 it's possible to bootstrap PowerMock using a JUnit
Rule instead of using the PowerMockRunner and the RunWith annotation.
This allows you to use other JUnit runners while still benefiting from
PowerMock's functionality. You do this by specifying:
#RunWith(Arquillian.class);
public class MyTest {
#Rule
PowerMockRule rule = new PowerMockRule();
// Tests goes here
...
}
See also the answers to Junit Parameterized tests together with Powermock - how? and the following thread in the PowerMock google group: Using PowerMock without the RunWith?.
No, you either need to:
use one and create a test base class that does the things you wanted the other runner to do.
separate your test into multiple tests, each using different runners.
JUnit4 only supports one #RunWith annotation, and JUnit4's #RunWith annotation doesn’t accept multiple runners.
Reference: project13
I'm writing some unit tests in my project and I have a datacontext dependency on the controller containing the methods I'd like to test.
I'm using Ninject to inject the dependency and Moq to create my mock datacontext. My DI makes use of an interface IDataContext which my dbml impliments and is used through out the injection process.
In my unit test I'm creating my mock datacontext as follows:
var mock = new Mock<IDataContext>();
var myController = new MyController(mock.Object);
This throws a Object reference not set to an instance of an object. exception on the second line whilst executing the datacontexts constructor.
I'm clearly missing a fundamental piece in setting this up however most of the Moq examples I've seen involve some kind of test against the mocked object using Setup().
Am I going about this the right way? Should I be creating a mock of my IDataContext interface or something else?
haha,
the answer came while i was reading through emad's blog on unit testing in ASP.Net MVC.
I'm guessing that you didn't add the connection string to the app.config of your test project right? :)
And that's the database dependency way because you're still not mocking the database end.
So if you want to do that, you need to google up for some codes, there are a few ways to do that.
i find these few references below to be quite useful, but since i don't really have a need to mock the database end, i'm just using my test DB server for now.
link
A little background:
I am Using Spring 2.5, and specifically Spring IOC and annotations.
I am using #Autowired in my code (the Autowiring is done by type)
and use #Component for exposing classes to the automatic wiring.
The situation described below arose while I tried to test my code.
Now to the problem:
Note: I use a different Spring Context for the Test environment.
I have a class FOO which is #Autowired but in the test context I want to use a different class of the same type MockFoo (extends FOO).
The Spring setup of course fails automatically due to multiple options for the Dependency Injection of the FOO class (both FOO and MockFOO comply to the Type check).
I am looking for a way to inject the test bean instead of the original bean.
I expected Spring to allow using the Context configuration file to override a bean injection or to order Spring not to autowire a specific bean.
BUT
All these options seem to exists only for the beans which were originally defined in the Spring Context Configuration file.
Use ReflectionTestUtils to manually set the Mock in place of the autowired dependency (for that purpose your mock must not be spring managed, so that no ambiguity exists)
I know this question is quite old but a I think an answer might still be useful for others.
Since you probably do not want to mix both Foo and MockFoo within your context, I would suggest to remove Foo from the component-scanning. This could be done for example by specifying include/exclude filters on the <context:component-scan>.
However if you are implementing unit tests, I would rather suggest not using a Spring context and just implementing "pure" unit tests by injecting mock-ups of the dependencies manually, so that you are only testing a single class. This can be achieved more easily by using a mocking framework like Mockito.
I agree with Didier. Here is an example of how you can exclude the implementations that you want to mock in your test application context.
<context:component-scan base-package="com.company" >
<context:exclude-filter type="regex" expression="com\.abc\.service\.XDaoImpl"/>
</context:component-scan>
Include this application context in your test as follows :
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations={"classpath:/applicationContext-test.xml"})
public class MyTest {....}