Develop Reference

Unit test existence of a directory - Junit

I have a function that I use to detect whether a certain directory path exists. Here's the function:
public boolean isRunningOnSandbox() {
return Files.isDirectory(Paths.get("/mySandbox/cloud/sandbox"));
}
As you can see, it relies on static method isDirectory. In my team, we do not use PowerMock for testing.
So, how can I test this method? I have tried writing a test like:
#Rule
public TemporaryFolder temporaryFolder;
#Test
public void test() throws IOException {
File parent = new File("/");
temporaryFolder = new TemporaryFolder(parent);
temporaryFolder.create();
File folder = temporaryFolder.newFolder("mySandbox", "cloud", "sandbox");
subject.isRunningOnSandbox();
}
But, I get an error
ava.io.IOException: Permission denied
because it doesn't let me create a temporary folder under the root. I am guessing there is a better way to test this code instead of trying to create a folder.

There are many ways to do it, onee of them migh be like the below one.
Assumming that isRunningOnSandbox method is in some class SomeClass, then refactor this class in this way:
public class SomeClass {
public boolean isRunningOnSandbox() {
return Files.isDirectory(Paths.get(getSanboxPath()));
}
protected String getSanboxPath(){
return "/mySandbox/cloud/sandbox";
}
}
and then in your tests inject into this class another directory to which you have access, for example:
public class SomeClassTest {
class SomeClassToTest extends SomeClass{
String folder;
public SomeClassToTest(String folder){
this.folder = folder;
}
#Override
protected String getSanboxPath(){
return folder;
}
}
static String sandboxFolder = "myTestSandobxFolder";
static Path tempDir;
#BeforeClass
public static void createFolder() throws IOException {
tempDir = Files.createTempDirectory(sandboxFolder);
}
#AfterClass
public static void deleteFolder() throws IOException {
Files.delete(tempDir);
}
#Test
public void IsRunningOnSandbox_shouldReturnTrueWhenPathExists() throws IOException {
//given
SomeClass testedObject = new SomeClassToTest(tempDir.toString());
//when
boolean result = testedObject.isRunningOnSandbox();
//then
assertThat(result).isTrue();
}
#Test
public void IsRunningOnSandbox_shouldReturnFalseWhenPathDoesNotExist() throws IOException {
//given
SomeClass testedObject = new SomeClassToTest("/abcdef123");
//when
boolean result = testedObject.isRunningOnSandbox();
//then
assertThat(result).isFalse();
}
}

The function you have shown is not suited for unit-testing: With unit-testing you try to find the bugs in small, isolated software pieces. But, which bugs could be in this example code that are not related to the other components, that is, the Files component, the Paths component and the actual file system?
The potential bugs in your example are about questions like "am I calling the right functions?" or "do I call the functions with proper values for the arguments?" or "do the functions I call return arguments as I expect" or "am I using the path that is also the path found in the file system". This can not be checked with unit-testing, but with integraton-testing.
Imagine you have the wrong path in mind. Then, in your unit-test you would also check against the same wrong path, and your unit-test would succeed. Only when running that test as an integration test on the real file system you could figure out that the path which you had in mind was wrong and did not match the actual path in the file system.

Issue with Powermockito verifystatic

I have a legacy class which has a static void method which i need to test:
public class A {
public static void renameTo()
{
String ext = "." + this.fileName + ".backup";
for (File file : getCSVFile()) {
f.renameTo(new File(file.getAbsolutePath() + ext));
}
public static File[] getAllFiles()
{
//logic to read the CSV files from the class path
}
}
Now I have written a test case for it using PowerMockito which looks like this. Now the issue is, even though the renameTo() is called only, if i call PowerMockito.verifyStatic( Mockito.times(10)) the test still passes
#RunWith(PowerMockRunner.class)
#PrepareForTest(A.class)
#PowerMockIgnore("javax.management.*")
public class ATest {
#Test
public void testRenameTo() throws Exception {
PowerMockito.mockStatic(A.class);
A.renameTo();
PowerMockito.verifyStatic( Mockito.times(1));
//PowerMockito.verifyStatic( Mockito.times(5));//Passes even though the mehod is called only once
//PowerMockito.verifyStatic( Mockito.times(10);//Passes even though the mehod is called only once
}
}
Could someone please shed some light into this issue? what I may be doing wrong?

As per the documentation, after the test verifyStatic needs to be called first, then call A.renameTo() to tell it which static method to verify. Example:
// run test
A.renameTo();
// verify interaction
PowerMockito.verifyStatic(A.class, Mockito.times(1));
A.renameTo();

How to test File.delete() function in Junit

I have one method like below:
public final class someTask {
public void sampleMethod(String filePath) {
//It is calling Files.delete() method.
Files.delete(new File(filePath).toPath)
}
}
When I test above method(for example ValidRecord in that file, Valid file parameter or not etc) test cases, most of the time my test case failed. Please some one can help me how to test for above cases.
To get file I am using below snippet
#Mock
File fileMock;
#Rule
ExpectedException exception = ExpectedException.none();
PowerMockito.whenNew(File.class).withArguments(VALID_Path).thenReturn(fileMock);
PowerMockito.when(fileMock.exists()).thenReturn(true);
PowerMockito.when(fileMock.isFile()).thenReturn(true);
In this, I am not planning to test Files.deplete() method but I am planning test behaviour of my own method. In that process every time I am getting "java.nio.file.NoSuchFileException" exception even I create temporary file.
Please some can provide with example, how to test this.

One might argue that your approach is wrong by verifying the behaviour through mocking and interactions. I would do the following
Create a temp file on local file system
Call the method sampleMethod
Verify that the file doesn't exist anymore.

A valuable approach to such kinds of question is to go one step back criticize your application design. Ask yourself, whether you have design issues, especially when you feel that testing your code seems to be a bit difficult.
And indeed: You can/should improve the design of your software!
Let's start with your class (btw, I changed names to camel-casing):
public final class SomeTask {
public void sampleMethod(String filePath) {
Files.delete(new File(filePath).toPath);
}
}
I am going to ignore exceptions. Also, somewhere in your code you are using this class:
SomeTask task = new SomeTask();
String filePath = ...
task.sampleMethod(filePath);
The first thing to realize: In your class SomeTask you have a dependency to a delete-a-file functionality. Make this dependency visible!
But how do you do that? With an interface:
#FunctionalInterface
public interface FileDeletor {
void delete(String filePath);
}
You now can change your class by adding a field for such a deletor:
public final class SomeTask {
private final FileDeletor deletor;
public SomeTask(FileDeletor deletor) {
this.deletor = Objects.requireNonNull(deletor);
}
public void sampleMethod(String filePath) {
deletor.delete(filePath);
}
}
With this approach you delegate the technical doing of a file deletion to another class that now must implement the interface (shown below). This also makes your class more coherent because it now can concentrate on its own feature(s).
We now need a class that implements that interface:
public final class DefaultFileDeletor implements FileDeletor {
#Override
public void delete(String filePath) {
Files.delete(new File(filePath).toPath());
}
}
Note, that I am still ignoring exceptions here. Now we must also change the using side:
FileDeletor deletor = new DefaultFileDeletor();
SomeTask task = new SomeTask(deletor);
String filePath = ...
task.sampleMethod(filePath);
With this approach you can also build up an application via Spring autowiring or similar dependency injection frameworks.
Let us move on to the testing area. If you wish, you can also test your new class DefaultFileDeletor. But you know that it only uses a JDK functionality which itself is tested enough. No need to test this simple class.
But how can you now test your class SampleTask? First, you need an implementation of the interface just for the purposes of testing:
public class FileDeletorForTestPurposes implements FileDeletor {
private String filePath;
private boolean deleted;
#Override
public void delete(String filePath) {
this.filePath = filePath;
deleted = true;
}
public String getFilePath() {
return filePath;
}
public boolean isDeleted() {
return deleted;
}
}
Now you are able to test your code:
FileDeletorForTestPurposes deletor = new FileDeletorForTestPurposes();
SomeTask task = new SomeTask(deletor);
String filePath = ...
task.someMethod(filePath);
assertEquals(filePath, deletor.getFilePath());
assertEquals(true, deletor.isDeleted());
You are now also able to simply create a FileDeletor mock and use that by expressing expectations on it.

How to test delete files with Files.delete fuction below is the example
Lets say you have one function like below
public boolean deleteFilesWithinPath(Path path, int retryCount){
boolean status=false;
while (retryCount < 3) {
try {
Files.delete(path);
LOG.info("File deleted successfully from work Dir");
status=true;
break;
} catch (IOException e) {
try {
LOG.error(e.getMessage());
LOG.info("File was not deleted . Retrying ..");
status=false;
Thread.sleep(2000);
retryCount++;
} catch (InterruptedException e1) {
status=false;
LOG.error(e1.getMessage());
Thread.currentThread().interrupt();
}
}
}
return status;
}
Then you can test above function like below with Powermockit or Mockito
#Test
public void testdeleteFilesWithinPath() throws Exception{
File mockFileTemp = temporaryFolder.newFile("test.csv");
PowerMockito.mockStatic(Paths.class);
PowerMockito.mockStatic(Files.class);
int retrycount=0;
Path path = mockFileTemp.getAbsoluteFile().toPath();
boolean status = mftFileDownloadServiceImp.deleteFilesWithinPath(path,retrycount);
assertTrue(status);
}
#Test
public void testdeleteFilesWithinPathForIOException() throws Exception{
File mockFile = temporaryFolder.newFile("test.csv");
PowerMockito.mockStatic(Paths.class);
PowerMockito.mockStatic(Files.class);
Path path = mockFile.getAbsoluteFile().toPath();
Files.delete(path);
int retrycount=0;
try{
mftFileDownloadServiceImp.deleteFilesWithinPath(path,retrycount);
} catch (Exception e) {
assertThat(e).isInstanceOf(IOException.class);
}
}

Javassist API with Junit

I am attempting to change some third party class definitions, before each test, to simulate different results. I have to use something like javassist because extending the classes, sometimes, is just not possible due to the access modifiers. Here is an example of what I am attempting to do with javassist and junit combined:
public class SimulatedSession extends SomeThirdParty {
private boolean isJoe = false;
public SimulatedSession(final boolean isJoe) {
this.isJoe = isJoe;
}
#Override
public void performThis() {
final ClassPool classPool = ClassPool.getDefault();
final CtClass internalClass = classPool.get("some.package.Class");
final CtMethod callMethod = internalClass.getDeclaredMethod("doThis");
if (isJoe) {
callMethod.setBody("{System.out.println(\"Joe\");}");
} else {
callMethod.setBody("{System.out.println(\"mik\");}");
}
internalClass.toClass();
}
}
#Test
public void firstTest() {
SimulatedSession toUse = new SimulatedSession(false);
// do something with this object and this flow
}
#Test
public void nextTest() {
SimulatedSession toUse = new SimulatedSession(true);
// do something with this object and this flow
}
if I run each test individually, I can run the code just fine. When I run them using the unit suite, one test after the other, I get a "frozen class issue". To get around this, I am looking at this post, however, I must admit I am unsure as to how one can use a different class pool to solve the issue.

Your current code will try to load twice the same class into the same ClassLoader which is forbidden, you can only load once a class for a given ClassLoader.
To make your unit tests pass, I had to:
Create my own temporary ClassLoader that will be able to load some.package.Class (that I replaced by javassist.MyClass for testing purpose) and that will be implemented in such way that it will first try to load the class from it before the parent's CL.
Set my own ClassLoader as context ClassLoader.
Change the code of SimulatedSession#performThis() to be able to get the class instance created by this method and to call internalClass.defrost() to prevent the "frozen class issue".
Invoke by reflection the method doThis() to make sure that I have different output by using the class instance returned by SimulatedSession#performThis() to make sure that the class used has been loaded with my ClassLoader.
So assuming that my class javassist.MyClass is:
package javassist;
public class MyClass {
public void doThis() {
}
}
The method SimulatedSession#performThis() with the modifications:
public Class<?> performThis() throws Exception {
final ClassPool classPool = ClassPool.getDefault();
final CtClass internalClass = classPool.get("javassist.MyClass");
// Prevent the "frozen class issue"
internalClass.defrost();
...
return internalClass.toClass();
}
The unit tests:
// The custom CL
private URLClassLoader cl;
// The previous context CL
private ClassLoader old;
#Before
public void init() throws Exception {
// Provide the URL corresponding to the folder that contains the class
// `javassist.MyClass`
this.cl = new URLClassLoader(new URL[]{new File("target/classes").toURI().toURL()}){
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
try {
// Try to find the class for this CL
return findClass(name);
} catch( ClassNotFoundException e ) {
// Could not find the class so load it from the parent
return super.loadClass(name, resolve);
}
}
};
// Get the current context CL and store it into old
this.old = Thread.currentThread().getContextClassLoader();
// Set the custom CL as new context CL
Thread.currentThread().setContextClassLoader(cl);
}
#After
public void restore() throws Exception {
// Restore the context CL
Thread.currentThread().setContextClassLoader(old);
// Close the custom CL
cl.close();
}
#Test
public void firstTest() throws Exception {
SimulatedSession toUse = new SimulatedSession(false);
Class<?> c = toUse.performThis();
// Invoke doThis() by reflection
Object o2 = c.newInstance();
c.getMethod("doThis").invoke(o2);
}
#Test
public void nextTest() throws Exception {
SimulatedSession toUse = new SimulatedSession(true);
Class<?> c = toUse.performThis();
// Invoke doThis() by reflection
Object o2 = c.newInstance();
c.getMethod("doThis").invoke(o2);
}
Output:
mik
Joe

Take a look at retransformer. It's a Javassist based lib I wrote for running tests just like this. It's a bit more terse than using raw Javassist.

Maybe another approach. We had a similar problem as we once mocked a dependency - we could not reset it. So we did the following: Before each test we replace the 'live' instance with our mock. After the tests, we restore the live instance. So I propose that you replace the modified instance of your third party code for each test.
#Before
public void setup()
{
this.liveBeanImpl = (LiveBean) ReflectionTools.getFieldValue(this.beanToTest, "liveBean");
ReflectionTools.setFieldValue(this.beanToTest, "liveBean", new TestStub());
}
#After
public void cleanup()
{
ReflectionTools.setFieldValue(this.beanToTest, "liveBean", his.liveBeanImpl);
}
The setFieldValue looks like this:
public static void setFieldValue(Object instanceToModify, String fieldName, Object valueToSet)
{
try
{
Field declaredFieldToSet = instanceToModify.getClass().getDeclaredField(fieldName);
declaredFieldToSet.setAccessible(true);
declaredFieldToSet.set(instanceToModify, valueToSet);
declaredFieldToSet.setAccessible(false);
}
catch (Exception exception)
{
String className = exception.getClass().getCanonicalName();
String message = exception.getMessage();
String errorFormat = "\n\t'%s' caught when setting value of field '%s': %s";
String error = String.format(errorFormat, className, fieldName, message);
Assert.fail(error);
}
}
So maybe your tests will pass if you reset your implementation for each test. Do you get the idea?

Unit: How to write test case using jUnit and Mockito

I am very new to Mockito and jUnit and TDD in general and I try to learn the right way to do TDD. I need couples of example to kick start my brain. SO please help me
So I have a method getNameInc(String dirPath, String filenName). So given a fileName like bankAccount.pdf, and if in this folder, no file name bankAccount.pdf, then return bankAccountAA.pdf. If there is exist one bankAccount.pdf then return bankAccountBB.pdf The increment is AA-ZZ. When it reach ZZ then it roll back to AA. I already implement the logic of this method. How do I unit test this method using Mockiti and jUnit?
EDIT
Here is the class and methods that are involved.
public class PProcessor{
private final Map<Integer, String> incMap = new HashMap<Integer, String>();
private String getNameInc(String dirPath, String filenName){
String[] nameList = new File(dirPath).list(new FilenameFilter(){
public boolean accept(File file, String name) {
//only load pdf files
return (name.toLowerCase().endsWith(".pdf"));
}
});
//Return the number of occurance that a given file name appear
//inside the output folder.
int freq = 0;
for(int i=0; i<nameList.length; i++){
if(fileName.equals(nameList[i].substring(0, 8))){
freq++;
}
}
return incMap.get(freq);
}
private void generateIncHashMap(){
incMap.put(new Integer(0), "AA");
incMap.put(new Integer(1), "BB");
incMap.put(new Integer(2), "CC");
...
}
}
generateIncHashMap() will be called in the constructor to pre-generate the hash map

You are trying to test your getNameInc(..) method, I assume. When you call it, it looks for the files in the directory you specify, and based on what it finds, decorates the name you gave it.
To make the class unit-testable, you should abstract the dependency on the file system, so that in a mock, you can simulate whatever directory contents you want. Your class will accept an instance of this interface as a dependency, and call it to find out what's in the directory. When you use the class in your program for real, you will supply an implementation of this interface that delegates to the JDK filesystem calls. When you unit-test the class, you will supply Mockito mocks of this interface.
Avoid putting too much logic into the FilesystemImpl class, since you can't write a strict unit test for it. Keep it a very simple wrapper around the filesystem, so that all the intelligent stuff is in Yourclass, which you will write plenty of unit tests for.
public interface Filesystem {
boolean contains(String dirpath, String filename);
}
public class FilesystemImpl {
boolean contains(String dirpath, String filename) {
// Make JDK calls to determine if the specified directory has the file.
return ...
}
}
public class Yourmainclass {
public static void main(String[] args) {
Filesystem f = new FilesystemImpl();
Yourclass worker = new Yourclass(f);
// do something with your worker
// etc...
}
}
public class Yourclass {
private Filesystem filesystem;
public Yourclass(Filesystem filesystem) {
this.filesystem = filesystem;
}
String getNameInc(String dirpath, String filename) {
...
if (filesystem.contains(dirpath, filename) {
...
}
}
}
public class YourclassTest {
#Test
public void testShouldAppendAAWhenFileExists() {
Filesystem filesystem = Mockito.mock(Filesystem.class);
when(filesystem.contains("/some/mock/path", "bankAccount.pdf").thenReturn(true);
Yourclass worker = new Yourclass(filesystem);
String actual = worker.getNameInc("/some/mock/path", "bankAccount.pdf");
assertEquals("bankAccountAA.pdf", actual);
}
#Test
public void testShouldNotAppendWhenFileDoesNotExist {
Filesystem filesystem = Mockito.mock(Filesystem.class);
when(filesystem.contains("/some/mock/path", "bankAccount.pdf").thenReturn(false);
Yourclass worker = new Yourclass(filesystem);
String actual = worker.getNameInc("/some/mock/path", "bankAccount.pdf");
assertequals("bankAccount.pdf", actual);
}
}
Since there's a lot of duplication between the tests, you'd probably create a setup method and do some of the work there, and create some instance variables for the tests to use:
private static final String TEST_PATH = "/some/mock/path";
private static final String TEST_FILENAME = "bankAccount.pdf";
private Filesystem filesystem;
private Yourclass worker;
#Before
public void setUp() {
filesystem = Mockito.mock(Filesystem.class);
worker = new Yourclass(filesystem);
}
#Test
public void testShouldAppendAAWhenFileExists() {
when(filesystem.contains(TEST_PATH, TEST_FILENAME).thenReturn(true);
String actual = worker.getNameInc(TEST_PATH, TEST_FILENAME);
assertEquals("bankAccountAA.pdf", actual);
}
etc...

For what you have described there I wouldn't bother with Mockito, there doesn't seem to be anything to mock (because it is easy to manipulate the file system).
I would test ...
- What happens if I call getNameInc and there are no matching files already
- What happens if I call getNameInc and there are files AA-YY there already
- What happens if I call getNameInc and file ZZ is there already
The point of TDD though is that you should have already written these tests and then implemented your code to make the tests pass. So you won't really be doing TDD since you already have the code.