I'm using JUnit and Mockito to test some classes. The class itself creates an object from another class. A list called testList. Here my code:
public class A {
private List<B> bList;
//returns the bList
public List<B> getBList() {
return bList;
}
//checks the status by calling getStatus in class B
public Status getStatus() {
//status is an enum consists of PASSED and FAILED
Status finalStatus = Status.PASSED;
for (B be : this.getTestList()) {
if (be.getStatus() != Status.PASSED) {
finalStatus = Status.FAILED;
break;
}
}
return status;
}
}
public Class B {
private Status status = Status.FAILED;
public getStatus() {
return status;
}
public void setStatus(Status status) {
this.status = status;
}
}
What would be the best way to test the getStatus and getTestList methods in the class called Test.
Thank you very much....
I looked at your ClassA and I wondered how bList ever gets set to anything. Right now, there's no way for it to be anything other than null, which means that getStatus will throw a null pointer exception every time.
Your problem is that you are thinking about how to test methods instead of thinking about how to test behaviour. One reason why this is a problem is that your class has to fit in with the rest of your application in a certain way. To be sure that it does that, it needs certain behaviour, not certain details within each method. So the only meaningful test is one that checks the behaviour.
Perhaps more insidious is the fact that testing individual methods makes you focus on the code that you have in fact written. If you are looking at your code while you write your test, then your test becomes a self-fulfilling prophecy. You may have missed a whole set of behaviour that your class is required to provide; but if you only test the behaviour that your class does provide, you'll never know.
So, back to the problem in hand. I see four, maybe five behaviours that your class might be expected to fulfil. Maybe there are more - it's hard to tell if you only show us the code, and not the specification. You should write a test for each one. I strongly believe that the name of each test should describe the behaviour, rather than reflecting the name of the methods that the test uses. In this case, I might choose names like this.
public void statusIsPassedWhenEveryTestPassed()
public void statusIsFailedWhenEveryTestFailed()
public void statusIsFailedWhenSomeTestsPassedSomeFailed()
public void statusIsPassedWhenNoTests()
public void statusIsPassedWhenTestsNotSet() // this one currently fails
Within each test, I would create an object of ClassA, then do whatever has to be done to set the bList within the object. Lastly, I would call getStatus and assert that the return value is what I want. But the important point is that each test (except the last one) uses more than one method of ClassA, so these are not tests of an individual method.
You can provide setters (or constructor injection) for the objects in question as protected and then extend the class inside your test case to mock the objects or you can try using something like powermock. You would still need to provide a way to set those objects in question.
I guess it depends on how you can populate testList in a unit test. If you have, say, a setter, then you would not need any mocking frameworks
class TestTest {
Test test = new Test();
#Test void should_return_failed_if_a_single_test_failed() {
givenTestListWithOneFailedTest();
assertThat(test.getStatus(), is(Status.FAILED))
}
void givenTestListWithOneFailedTest() {
test.setTestList(createSomeTestListWithOnlyOneFailedTest());
}
#Test void should_return_passed_if_all_tests_passed() {
// ...
}
}
Related
first of all: I found few solutions for my problem but the "newest" one was from 2014 and used reflections so I hope I could maybe find some more advanced solutions for my question.
Thats the case and its about migrateUser and canAdd. This is an example class to make my question easily visible.
public class UserInterfaceImpl implements UserInterface {
private final List<T> accountList = new LinkedList<>();
private final AccountInterface accountInterface;
private boolean bonusReceived = false;
public UserInterfaceImpl(AccountInterface accountInterface) {
this.accountInterface = accountInterface;
}
public void migrateUser(AccountMergerInterface accountMerger, UserInterface oldUser) {
boolean success = accountMerger.performChange(this, oldUser);
if (success && !bonusReceived) {
//addBonus
accountInterface.deposit(1);
bonusReceived = false;
}
}
public boolean canAdd() {
return accountList > 0;
}
public AccountInterface getAccount() {
return accountInterface;
}
}
The migrateUser method changes the some account Data which is not relevant for my test because I would test it separately of course (should be like that what I read so far).
So I wonder, how can I see if the behavior of that class changes the bonusReceived correctly? Without using reflections and do it as sophisticated as possible?
My first attempt was that:
#Test
public void testMigrateUser() {
AccountMergerInterface test = mock(AccountMergerInterface.class);
// define return value for method getUniqueId()
when(test.performChange()).thenReturn(true);
}
But now I cannot continue. The rule should be in my example to have no getter and setter! The class should be like my example.
I don't know how to:
set bonusReceived to false before migrateUser is executed that accountInterface.deposit(1); is not executed
see if bonusReceived will be set to false if the if() continue is true.
Same questions for the List: how can I access the private field of List, add an Object so that the return value is true or false. Or should I "simulate" a List and if yes, how can I do that?
Thanks in advance!
Unit tests check public observable behavior.
There is no point in verifying internal state of an object since this may change to support other behavior. You don't want to change your unit test in that case...
So mock the AccountMergerInterface (as you already did) and the AccountInterface and verify that your class under test calls the methods on them in the right order with the right parameters:
#Rule
public MockitoRule mockitoRule = MockitoJUnit.rule();
#Mock
private AccountMergerInterface accountMergerInterface;
#Mock
private AccountInterface accountInterface;
#Test
public void testMigrateUser() {
// arrange
when(test.performChange()).thenReturn(true);
// act
new UserInterfaceImpl(accountInterface).migrateUser(accountMergerInterface);
// assert
InOrder inOrder Mockito.inOrder(accountMergerInterface, accountInterface);
inOrder.verify(accountMergerInterface).deposit(1);
inOrder.verify(accountInterface).whatEverToCallNext();
}
Same questions for the List:
There is currently no code dealing with the list in UserInterfaceImpl.
You cannot verify behavior which is not there...
If I have something like this:
public class Set {
private ArrayList<String> testList;
private String testString;
public Set() {
}
public void add(String testString) {
testList.add(testString);
}
public String toString() {
StringBuilder sb = new StringBuilder();
sb.append(testString).append(System.getProperty("line.separator"));
return sb.toString();
}
}
How can I test this in a main method?
This is what I've tried so far...
Set test = new Set();
test.add("blah");
test.add("blahhh");
System.out.println(blah.toString());
Am I doing this correctly? Taking my first CS course in High School and we're supposed to make a class that implements a toString() method.
you creacted the object test of the class Set just write now just:
System.out.println(test);
will give you the result you want since it will use the toString method
and your testString is not set so the toString will return null
You can test your toString this way, but for this purpose you should use Unit Tests (see junit).
For testing your Class you should try it with different types of input, to see, what happens, if someone enteres something unexpected.
And you have errors in your Code:
Set test = new Set();
test.add("blah");
test.add("blahhh");
System.out.println(blah.toString());
There is no blah variable:
System.out.println(test.toString());
or just:
System.out.println(test);
For learning purposes you should do something more usefull in your toString. You could try to create a Class bank account with balance, owner data (name, address, ...) and creating in the toString an interesting output.
You are asking about testing; then dont go for print statements.
Turn to a unit test environment, like JUnit; and write real tests:
#Test
public testToStringWithTwoEntries() {
Set underTest = new Set();
underTest.add(...
assertThat(underTest.toString(), is("blah, blahhh"));
}
for example. Notes:
assertThat() is simply one of the most powerful of the various different assert methods; and it is easy to use; one just has to understand that it requires Hamcrest matchers to work (that is where the is() call is coming from)
you named your class "Set" ... bad idea. There is already a well-known interface java.util.Set. You never want to re-use such names.
A very good library for testing toString on model classes: https://github.com/jparams/to-string-verifier
Sample:
#Test
public void myTest()
{
ToStringVerifier.forClass(Set.class).verify();
}
I'm very new to unit testing, I'm wondering if there is a way to test a method without initializing the class. The reason I'm asking is because there are lot of object passing in the constructor meaning a lot of mocking stubbing while from a thorough check methodToTest seems not to use any object attribute. It's not my code otherwise the method could be converted to static.
class ExampleClass {
public ExampleClass(FirstClass fc, SecondClass sc, ThirdClass tc) {}
public void methodToTest(FourthClass foc) {}
}
You have some options here:
Make the method static so you don't need a reference to an actual object. This will only work if the method does not need any state of ExampleClass (i.e. everything it needs is passed in the method arguments).
Extract this method to another class (perhaps using the method object pattern) that's easier to test on its own. This refactoring is called replace method with method object.
Usually, having to many parameters in constructors is a hint on bad conception. You'd better rethink you Objects and classes to reduce argument to give to the constructor.
If you don't want to, you can still use some kind of a "TestUtil" wich instantiate class for you.
Example :
public class MyTestUtils {
public createValidFirstClass() {
return new FirstClass(/* some arguments here */);
}
public createValidSecondClass() {
return new SecondClass(/* Some arguments here */);
}
public createValidThridClass() {
return new ThridClass(/* Some arguments here */);
}
public createValidExampleClass() {
return new ExampleClass(createValidFirstClass(), createValidSecondClass(), createValidThridClass());
}
}
This class MUST be in your test packages and not in your project, and should not be used outside of the tests, it would be a really bad practice here, use Factory or Builder for your real projects.
Anyway, i think that the best solution is to rethink you Classes.
Example :
public class People {
public People(String firstName, String lastName, Date birth, Date death) {
}
}
As you can see this is a pain in the ass to control that all given parameter was correctly formatted and not null.
This number of argument passed to a method can be reduced this way.
public class People {
public People(PeopleNames names, Period period) {
}
}
public class PeopleNames {
public People(String firstName, String lastName) {
}
}
public class PeopleNames {
public People(Date begin, Date end) {
}
}
Ok, it seems I found a way. Since the method is irrelevant to the state of the object, I could mock the object and order the MockRunner to use the real method when it is called. It is named partial mocking. The way of doing it is
ExampleClass = PowerMockito.mock(ExampleClass.class);
when(ExampleClass.methodToTest(foc)).thenCallRealMethod();
As far as I know, you cannot conduct a Test without initializing the class.
The three steps of Test are Arrange,Act and Assert. The class has to be initialized in the arrange part for fetching the required methods in the particular class you are testing.
I don't know what your method does but if it's possible for your application you could just make methodToTest static, which would allow you call it without an instance of the class.
Alternatively, you could avoid too much instantiation by creating one instance in a #BeforeClass method to be used for all tests, but again I don't know what you method does so that might not be desirable.
Use suppressions from PowerMockito.
import org.powermock.api.support.membermodification.MemberModifier;
import org.powermock.api.support.membermodification.MemberMatcher;
suppress(MemberMatcher.constructor(ExampleClass.class))
I'm using junt and jock.
Suppose I have an interface of an object, Contact, and a method like this one in my test class:
#Test
public void testAddOneContact() {
final Contact contact = this.context.mock(Contact.class);
this.addressBook.addContact(contact);
assertTrue("Object added to list", this.addressBook.getNumberOfContacts() == 1);
}
The method addContact is implemented in this way :
public void addContact(Contact contact) {
//Check if contact passed is valid. If it is, add it to address book
if(contact != null) {
this.contactsList.add(contact);
}
}
So you can see that I'm not calling any method of the Contact interface.
For this reason, I can't have any expectations in the test method testAddOneContact().
Is this a right way to implement a test case and use JMock (so even if I don't have any expectations)?
I will take a shot at this:.
Firstly, I do not see anything incorrect in the manner you have written the test.
Based upon the test case description I assume that the test case is for the AddressBook class which stores a list of contacts and that you are testing the method addContact exposed by the AddressBook class.
That said you can still make your class a bit more robust by doing something like below in the addContact method:
public void addContact(Contact contact) throws IllegalArgumentException
{
if(contact == null)
{
//throw an exception after logging that contact is null
throw new IllegalArgumentException("Passed in contact cannot be null!!")
}
this.contactsList.add(contact);
}
Now your test code for testAddOneContact will have to test two different input cases and this can be done as below using two separate test cases
#Test
public void testAddOneContact() {
final Contact contact = this.context.mock(Contact.class);
this.addressBook.addContact(contact);
assertTrue("Object added to list", this.addressBook.getNumberOfContacts() == 1);
//assuming that Contact class implements the equals() method you can test that the contact
//added is indeed the one that you passed in
assertTrue(addressBook.get(0).equals(contact));
}
//the below test ensures that there is exception handling mechanism within your library code
#Test
#Expected(IllegalArgumentException.class)
public void testShouldThrowWhenContactIsNull()
{
this.addressBook.addContact(null);
}
As an aside - Note how implementing a good test class makes you think about the design of the methods to be exposed as APIs and also how certain methods like hashCode and equals() need to be overridden. It also makes you think - 'how do I handle error cases?'. Such thoughtful questions are essential for ensuring that the code you are shipping solves exactly the problem which it is supposed to solve in an efficient and error-free manner.
Hope this helps
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Intercept object on method invocation with Mockito
I have an class that can mapp from one format to another. Since this is legacy code I don't dare to rewrite it, it is basically a set of plugins so if I change one I might have to change all the other. It wasn't developed with testing in mind.
So this is my problem.
interface Mapper {
void handle(ClassA classA);
void handle(ClassB classB);
}
public interface Publisher {
public void publish(MappedClass mappedClass);
}
class MyMapper implements Mapper {
private Publisher publisher;
public void setPublisher(final Publisher publisher) {
this.publisher = publisher;
}
public handle(ClassA classA) {
final MappedClass mappedClass = // Map from ClassA to MappedClass
publisher.publish(mappedClass);
}
public handle(ClassB classB) {
final MappedClass mappedClass = // Map from ClassB to MappedClass
publisher.publish(mappedClass);
}
}
Okay. So depending on which class was "handled" MappedClass will be published with different values, and it is the values I want to verify (test). The problem is that I will get a test where I first have to write code that tests that the publish method is called,
private boolean wasCalled;
#Test
public void testClassAMapped() {
wasCalled = false;
final MyMapper myMapper = new MyMapper();
myMapper.setPublisher(new Publisher() {
public void publish(final MappedClass mappedClass) {
wasCalled = true;
// Code for verifying the fields in mappedClass
});
}
final ClassA classA = // Create classA
myMapper.handle(classA);
assertTrue(wasCalled);
}
So first we create our mock Publisher which will first set the state of wasCalled to true so we know this method was ever called (this example is simplified so there is actually a dispatcher in the code... legacy code so I don't want to change it), second I want to verify that MappedClass has the correct field values.
What I would like to know is if anyone knows a better way to test this? The wasCalled, and wasCalled check becomes more or less boilerplate code for many of my tests, but since I don't want to add that much clutter (own hacks, test base classes, etc) I would like to know if there is a way to do this in Mockito, or EasyMock?
Use an Mockito ArgumentCaptor
#Test
public void test(){
Publisher publisher = Mockito.mock(Publisher.class);
myMapper.setPublisher(publisher);
ArgumentCaptor<MappedClass> captor = ArgumentCaptor.forClass(MappedClass.class);
....
myMapper.handle(...);
...
verify(publisher).publish(captor.capture());
MappedClass passedValue = captor.getValue();
// assert stuff here
}
I'm not sure I fully understand the problem, but it looks like you are looking for Mockito.verify(publisher).publish(Matchers.isA(MappedClass.class));
For that to work, you'd have to mock the Publisher through
Publisher publisher = Mockito.mock(Publisher.class)
and then hand that into MyMapper.
If you need to assert the state of the MappedClass, use an ArgumentCaptor. See this answer for an example.
The Mockito-API-doc has many additional examples.