How to use RunnerFactory class of org.mockito.internal.runners package

If I understood the task correctly it could be like this

static boolean isClosed;

public void run() {
    InputStream inputStream = null;
    try {
        inputStream = new FileInputStream(file) {
            @Override
            public void close() throws IOException {
                isClosed = true;
                super.close();
            }
        };
        // more stuff here

According to https://groups.google.com/forum/?fromgroups#!topic/mockito/9WUvkhZUy90, you should rephrase your

when(bar.getFoo()).thenReturn(fooBar)

to

doReturn(fooBar).when(bar).getFoo()

You either have to specify no matchers, or all the arguments need matches. So this:

when(userSubModuleDao.findById((any(UserSubModuleId.class)),false))

should be:

when(userSubModuleDao.findById(any(UserSubModuleId.class), eq(false)))

(I've removed the redundant brackets from around the any call.)

From the Matchers documentation:

Warning:

If you are using argument matchers, all arguments have to be provided by matchers.

use

MockitoAnnotations.openMocks(this);

This took me a while to figure out, so I am answering my own question.

import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.junit4.PowerMockRunner;

@RunWith(PowerMockRunner.class)  // important
@PrepareForTest(MachineImpl.class)  // important: do not use Thread.class here
public class MachineImplTest {

    private MachineImpl classUnderTest;

    @Before
    public void beforeEachTest() {
        classUnderTest = new MachineImpl();
    }

    @Test
    public void sleep_Pass() {
        classUnderTest.sleep(0);
        classUnderTest.sleep(-100);
        classUnderTest.sleep(+100);
    }

    @Test
    public void sleep_Pass2() {
        // We do not want to mock all methods, only specific methods, such as Thread.sleep().
        // Use spy() instead of mockStatic().
        PowerMockito.spy(Thread.class);

        // These two lines are tightly bound.
        PowerMockito.doThrow(new InterruptedException()).when(Thread.class);
        Thread.sleep(Mockito.anyLong());

        classUnderTest.sleep(0);
        classUnderTest.sleep(-100);
        classUnderTest.sleep(+100);
    }
}

If you are using TestNG, try this:

import org.mockito.Mockito;
import org.powermock.api.mockito.PowerMockito;
import org.powermock.core.classloader.annotations.PrepareForTest;
import org.powermock.modules.testng.PowerMockTestCase;

@PrepareForTest(MachineImpl.class)  // important: do not use Thread.class here
public class MachineImplTest
extends PowerMockTestCase {
    ...
}

Read more about TestNG + Mockito + PowerMock here: https://stackoverflow.com/a/35815153/257299

My answher: no, don't place references to repositories into you domain models. Place them into business services instead. And don't manage any security into domain at all. Security is refered to use cases, not domain logic, so security is placed over domain.

And I disagree with Sandhu. I'd use the following architecture:

1. Model classes. They don't get getters/setters for everything. It depends on model logic. Otherwise you get model where you can easily break consistency. Or where are many unobvious things. Suppose you have User.registrationDate field. When you construct a new User object, you should not forget to field registrationDate field by hands. So, just place registrationDate initialization in your constructor and remove setter!
2. Repository interface just inside your model. Suppose you have some business logic that depends on existing stored objects. You can't expliciltly refer from your domain logic into infrastructure dependencies like JPA, Hibernate, JDBC, etc. So you query this stored objects from interfaces.
3. Business services (optionally). They implement some complex logic, involving many different entities, not including security and transaction management. Your question is about it. Yes, if you need query for entities in your domain logic, place query into repository and call it from your business service.
4. Repository implementation inside infrastructure package. Implements repository interfaces using JPA or mockito or whatever else. They also don't include neither security nor transactions.
5. Application services (optionally). If there is some complex interaction with infrastructure or security checking.
6. Remote facade interface. Client and server communicate only through remote facade interface.
7. Remote facade implementation (controller). Transforms thick entity objects into thin DTOs (data transfer objects). All transaction demarcation and security is here (often using annotations).

This approach conforms DDD style, described by Martin Fowler. I think that JPA is musused in most of modern projects. It is used not as persistence provider, but as active record. Active record is not domain model implementation pattern, but database abstraction pattern. So if you really want transaction script approach, use some active record library or something like MyBatis instead of heavyweight JPA provider.

Also I don't understand the need of DAO. JPA providers do data abstraction themselves, don't they? Also data abstraction is not about model, but about infrastructure. So why is DAO placed over model? If you do really need DAO, you should place it under model (into repository implementation, I suppose).

Example of right usage:

package my.example.model;

@Entity
public class User {
    @Id
    @GeneratedValue
    private Integer id;
    private String login;
    private String password;
    @Temporal(TemporalType.TIMESTAMP)
    private Date registrationDate;

    User() {
        // for persistence provider only
    }

    public User(String login, String password) {
        this.login = login;
        this.password = hashPassword(password);
        this.registrationDate = new Date();
    }

    public String getLogin() {
        return login;
    }

    public String setPassword(String password) {
        this.password = hashPassword(password);
    }

    public boolean matchPassword(String password) {
        return this.password.equals(hashPassword(password));
    }

    public Date getRegistrationDate() {
        return registrationDate;
    }

    private static String hashPassword(String password) {
        try {
            MessageDigest digest = MessageDigest.getInstance("sha-1");
            StringBuilder sb = new StringBuilder();
            byte[] bytes = digest.digest(password.getBytes(charset));
            for (byte b : bytes) {
                sb.append(Character.forDigit((b >>> 4) & 0xF, 16)).append(Character.forDigit(b & 0xF, 16));
            }
            return sb.toString();
        } catch (NoSuchAlgorithmException e) {
            throw new AssertionError(e);
        }
    }
}

package my.example.model;

public interface UserRepository {
    User findByLogin(String login);

    User findBySurrogateId(int id);

    Integer getSurrogateId(User user);

    boolean contains(User user);

    void add(User user);

    void delete(User user);
}

package my.example.infrastructure;

@Component
public class PersistentUserRepository implements UserRepository {
    @PersistenceContext
    private EntityManager em;

    public void setEntityManager(EntityManager em) {
        this.em = em;
    }

    @Override public User findByLogin(String login) {
        // I'd use QueryDSL here
        QUser qusr = new QUser("usr");
        return new JPAQuery(em)
                .from(qusr)
                .where(qusr.login.eq(login))
                .singleResult(qusr);
    }

    @Override public User findBySurrogateId(int id) {
        return em.find(User.class, id);
    }

    @Override public Integer getSurrogateId(User user) {
        return (Integer)em.getEntityManagerFactory().getPersistenceUnitUtil().getIdentity(user);
    }

    @Override public boolean contains(User user) {
        return em.contains(user);
    }

    @Override public void add(User user) {
        em.persist(user);
    }

    @Override public void delete(User user) {
        em.remove(user);
    }
}

package my.example.facade;

public interface UserRemoteFacade {
    UserDTO getUser(String login);

    UserDTO getUser(int id);

    void changePassword(int userId, String newPassword);

    void registerUser(String login, String password) throws LoginOccupiedException;

    boolean authenticate(String login, String password);
}

package my.example.facade;

public class UserDTO implements Serializable {
    private int id;
    private String login;
    private Date registrationDate;

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getLogin() {
        return login;
    }

    public void setLogin(String login) {
        this.login = login;
    }

    public Date getRegistrationDate() {
        return registrationDate;
    }

    public void setRegistrationDate(Date registrationDate) {
        this.registrationDate = registrationDate;
    }
}

package my.example.server;

@Transactional @Component
public class UserRemoteFacadeImpl imlements UserRemoteFacade {
    private UserRepository repository;
    private Security security;

    @Autowired
    public UserRemoteFacadeImpl(UserRepository repository, Security security) {
        this.repository = repository;
        this.security = security;
    }

    @Override public UserDTO getUser(String login) {
        return mapUser(repository.findByLogin(login));
    }

    @Override public UserDTO getUser(int id) {
        return mapUser(repository.findBySurrogateId(id));
    }

    private UserDTO mapUser(User user) {
        if (user != security.getCurrentUser()) {
            security.checkPermission("viewUser");
        }
        UserDTO dto = new UserDTO();
        dto.setId(repository.getSurrogateId(user));
        dto.setLogin(user.getLogin());
        dto.setRegistrationDate(user.getRegistrationDate());
        return dto;
    }

    @Override public void changePassword(int userId, String newPassword) {
        User user = repository.findByLogin(login);
        if (user != security.getCurrentUser()) {
            security.checkPermission("changePassword");
        }
        user.setPassword(newPassword);
    }

    @Override public void registerUser(String login, String password) throws LoginOccupiedException {
        if (repository.findByLogin(login) != null) {
            throw new LoginOccupiedException(login);
        }
        User user = new User(login, password);
        repository.add(user);
    }

    @Override public boolean authenticate(String login, String password) throws LoginOccupiedException {
        User user = repository.findByLogin(login);
        return user != null && user.matchPassword(password);
    }
}

Also see this project: http://dddsample.sourceforge.net/

Lenient mocks are what you want, if you can't just use a real UserKeychain.

Mockito.lenient().when(userKeychain.getUserStatus()).thenReturn(UserState.OK);
Mockito.lenient().when(otherUserKeychain.getUserStatus()).thenReturn(UserState.SUSPENDED);

Mockito is designed to replace systems where you can't use the real system in your test, particularly in systems that predictably invoke services instead of getting properties from data objects (or other idempotent actions). Because your system doesn't call those methods in a deterministic order, and because the calls aren't expensive and don't have side effects, I would recommend just going with the "lenient" option.

Imagine this case instead, where you are testing deleting user 1001:

when(userRpc.deleteUser(1001)).thenReturn(RPC_SUCCESS);
when(userRpc.deleteUser(1002)).thenReturn(RPC_SUCCESS);  // unnecessary

The test might pass if you ever delete the wrong user: Over-stubbing has masked a problem. Compare with this:

when(userRpc.fetchExpensiveUserDetails(1001)).thenReturn(user1001);
when(userRpc.fetchExpensiveUserDetails(1002)).thenReturn(user1002);  // unnecessary

Depending on what you're testing, this might be dangerous, but might not be so bad. Simulating a slow mobile network or with expensive data, maybe it is entirely against spec for you to fetch too much. However, in other cases, it may be acceptable. Finally, compare this case:

when(calculationResult.getRealComponent()).thenReturn(-1d);
when(calculationResult.getComplexComponent()).thenReturn(5);
when(calculationResult.getShortString()).thenReturn("-1 + 5i");

calculationResult looks an awful lot like a data object, and it is probably not a critical part of your test which of your methods to call or whether you're calling all of them. This is a case where Mockito's strict stubbing hinders you rather than helping you, and might be a case where you want to make some of those stubbings lenient. You might also choose to make the entire mock lenient, which particularly makes sense if you were to create a test helper method like stubCalculationResult(-1, 5) that prepared an entire object for you like that.

The only option better than that is to use a real object. In my example, if CalculationResult is an existing well-defined object, it may be lower risk overall to use a real one than to mock the behavior you believe at test-writing time to be correct. Similarly for your case, if you have access to a UserKeychain constructor that populates UserStatus etc, then it may be safer to use that in a test.

Though this might appear at first glance to be a slippery slope into turning a unit test into an integration test, I'd like to clarify that I'm recommending this only for data objects, which have no dependencies, and which ideally are immutable objects that have no methods with side-effects. If you use dependency injection, these are the type of single-implementation data holders that you would call new on rather than getting from your graph. This is also a good reason to separate your data objects so they are immutable and easy to construct, and to shift your services to consume those objects rather than giving methods to the data objects (favoring loginService.login(user) rather than user.login(loginService)).

Try Cntrl + Shift + T on your eclipse screen. Check what are your results. Ideally eclipse should resolve this class only from one dependency. If you are getting multiple results, you may need to add exclusion on certain dependencies.

Also check if you are able to execute your test cases from command prompt. If you are able to do it, then it's not a maven problem. But if something is failing here, check your dependencies.

Answer is as below.

After consulting here http://code.google.com/p/powermock/issues/detail?id=278 , in fact Adder.add(12) above is part of setting up mock static method. It means when invoking Adder.add() with argument 12, IOException will be thrown. It is hard to understand, right? :) So it should be written as below.

PowerMockito.mockStatic(Adder.class);
PowerMockito.doThrow(new IOException()).when(Adder.class);
Adder.add(anyInt());

EDIT:
Link is dead, try Internet Archive one instead.