For some reason the test below fails on Windows, but passes on Linux. The test is designed to generate an exception in the code being tested. The exception is basically a file exception. The approach is to make the file unreadable in order to generate the exception. It looks like the setReadable(false) has no affect on Windows.
#Test(dependsOnGroups = "expectedFlow",expectedExceptions = ParserException.class)
#Parameters("unreadableFile")
public void mineDataParserExceptionTest(String unreadableFile) throws ParserException{
AbstractParser parser;
File f = new File(unreadableFile);
f.setReadable(false);
parser = ParserFactory.getParser(ParserFactory.TYPES.SAR);
parser.mine(fileHelper, xml);
}
You should check the return value to see if it succeeded; however, it seems likely that f.setReadable(false, false); might be a better idea, since otherwise it is only supposed to alter the read permission for the owner of the file.
Related
I have a method that I am trying to unit-test. I cannot post the actual code, but it looks like this:
public int getTotal() throws MyException {
int total = 0;
try (ExternalResource externalResource = ExternalService.getResource()) {
try (OtherExternal otherResource = externalResource.getOtherResource()) {
if (someCondition) {
total = otherResource.getTotal();
}
}
}
}
JaCoCo is telling me that I am missing 4/8 branches on each of the try-with-resource blocks. I am testing that someCondition is true and someCondition is false, and JaCoCo shows that block completely covered.
I read this question, and I understand from the accepted answer that the issue is in how the byte code is generated.
I would like to be able to better understand how to identify the various branches that are generated, and then I can make a better judgement on wether to test them or not (are they unreachable, etc).
Per the change history in version 0.8.2:
Branches and instructions generated by javac 11 for try-with-resources statement are filtered out
I've tested this out locally using openjdk java8, and my try-with-resources now reports 100% branch coverage (even though the IOException is never thrown in my tests).
While it is good to test this behavior out, there are times when you can't easily reproduce such exceptions. For instance, in a method that just returns an open port:
public int getOpenPort() {
try (ServerSocket boundSocket = new ServerSocket(0)) {
return boundSocket.getLocalPort();
}
}
I know of no simple way to force this code to throw IOException without adding a bunch of confusing and unnecessarily complicated code, just to pass a branch coverage check. Luckily, the new (v0.8.2) jacoco library gives this method 100% coverage with a single test just calling Assert.assertNotEquals(0, portChecker.getOpenPort());.
You have to test every Exception and every condition. But JaCoCo sometimes failed to identify correctly what is covered or not.
Hi I have test program which loads files into hdfs at this path user/user1/data/app/type/file.gz Now this test program runs multiple times by multiple users. So I want to set file permission to rwx so that anyone can delete this file. I have the following code
fs.setPermission(new Path("user/user1/data"),new FsPermission(FsAction.ALL,FsAction.ALL,FsAction.ALL))
Above line gives drwxrwxrwx to all dirs but for the file.gz it gives permission as -rw-r--r-- why so? Because of this reason another user apart from me not able to delete this file through test program. I can delete file through test program because I have full permssion.
Please guide. I am new to Hadoop. Thanks in advance.
Using FsShell APIs solved my dir permission problem. It may be not be optimal way but since I am solving it for test code it should be fine.
FsShell shell=new FsShell(conf);
try {
shell.run(new String[]{"-chmod","-R","777","user/usr1/data"});
}
catch ( Exception e) {
LOG.error("Couldnt change the file permissions ",e);
throw new IOException(e);
}
I think Hadoop doesn't provide a java API to provide permission recursively in the version you are using. The code is actually giving permission to the dir user/user1/data and nothing else. You should better use FileSystem.listStatus(Path f) method to list down all files in the directory and use Filsystem.setPermission to them individually. It's working currently on my 2.0.5-alpha-gphd-2.1.0.0 cluster.
However from Hadoop 2.2.0 onward a new constructor
FsPermission(FsAction u, FsAction g, FsAction o, boolean sb)
is being provided. The boolean field may be the recursive flag you wanted. But the documentation(including param name) is too poor to infer something concrete.
Also have a look at Why does "hadoop fs -mkdir" fail with Permission Denied? although your sitaution may be different. (in my case dfs.permissions.enabled is still true).
I wrote this in scala but I think you could easily adapt it:
def changeUserGroup(user:String,fs:FileSystem, path: Path): Boolean ={
val changedPermission = new FsPermission(FsAction.ALL,FsAction.ALL,FsAction.ALL, true)
val fileList = fs.listFiles(path, true)
while (fileList.hasNext()) {
fs.setPermission(fileList.next().getPath(),changedPermission)
}
return true
}
You will also have to add a logic for the error handling, I am always returning true.
I use Eclipse and Maven and have made a single JUnit test, just to test if it works. The first time I ran the test everything went as expected, but since then, every time I run it, I get the same result, even though I'm changing the actual test-file's content.
I tried just emptying the file, then it said that there are no JUnit test files. But as long as I just have #Test in front of a method in that file, I always get the same results.
Anyone know why that could be?
I tried restarting eclipse.
EDIT:
Just realized that I'm not getting the test results since there is an exception before it gets tested. So, the problem is that I'm always getting the exception even though I changed the file.
Testclass:
public class zipTester {
/**
* The class to be tested on.
*/
private Generator generator;
/**
* Sets up the generator.
*/
#Before
public void setUp() {
generator = new Generator(null, 0);
}
/**
* Creates a zip file and tests whether it exists.
*/
#Test
public void testCreateZip() {
File file = new File("/Users/nicola/Documents/trunk);
generator.createZip(file, new Vector<File>());
}
}
Changed TestClass:
public class zipTester {
#Test
public void heyo() {
}
}
Always getting the following Exception:
java.io.FileNotFoundException: /Users/nicola/Documents/trunk (No such file or directory)
...
1 May be you should clean your project
2 and then recheck project-BuildAutomatically
if still have something wrong,
you can right-click your project "java build path" and open the first tab Source
set default output folder content "test/target/classes"
good luck :)
i think your code was not compiled by eclipse
Seems that happen when there is no file in the relevant location.Because you are passing the file to Generator and try to access that file.Then this exception happen as there are no file to access with generator.
You can follow the below steps to avoid this scenario.
First check is that file exist in that location as below,
File file = new File("/Users/nicola/Documents/trunk");
assertTrue(file.exists());
Then check with your Generator.
I have a code that that reads parameters from XML file. In debugger everything works fine, but after I built JAR file and run it - I get the following window
Java Virtual Machine Launcher
A Java Exception has occured.
But if I comment this piece of code:
else if (settingName.equals("log_level")) {
String value = element.getAttribute("value");
if (value.equals("full")) {
modelLogLevel = EnLogDetails.LOG_FULL;
} else if (value.equals("apdu")) {
modelLogLevel = EnLogDetails.LOG_APDU;
} else if (value.equals("none")) {
modelLogLevel = EnLogDetails.LOG_NONE;
} else {
throw new InvalidArgumentException(new String[]{"log_level"});
}
}
and rebuild JAR again - it works fine. How to fix this issue?
You've provided exactly none of the relevant information, such as the actual exception or the command line you are using, but clearly you are supplying a log_level argument that doesn't match any of those tests, so you are throwing an IllegalArgumentException which is terminating main() and therefore the launcher. If so it is a complete mystery to me why you need to come to StackOverflow to have your own code explained to you.
Or else the references to EnLogDetails are failing in some way which is shown in the exception which you haven't supplied.
I am writing a "Total Commander" like application in Java. There is quite obvious file system dependency here.
I want to unit test it. I created directory structure for test purposes, I keep it in known location in SVN repository. It works great so far.
Now, I have a method that should ignore hidden files. How can I go about this? Can I mark file hidden in the SVN somehow?
Other solution would be to make one of the files hidden in the build script before running tests, but I'm afraid this would mark file as modified and always show in a commit dialog.
Any suggestions?
I would put all the initialization of a test directory into the tests themselves. And such a case would be simple:
create a directory
put some hidden and visible files into it
test
tear down by removing the directory
Essentially, accessing the file system is a big no-no when unit testing. For starters, these tests are slow(er) than your in-system tests, thus reducing the likelihood of you running your tests at a high frequency (such as with every compilation).
Much better if you use an adapter-pattern to abstract away the access to the file system. I'm a .NET developer so my example will be in C#, but I expect you to be able to translate it simply enough:
public class MyManager
{
private readonly IFileAdapter _fileAdapter;
public MyManager(IFileAdapter fileAdapter)
{
_fileAdapter = fileAdapter;
}
}
public interface IFileAdapter
{
public FileStream Open(string fileName);
public string ReadLine(FileStream fileStream);
// More methods...
}
public class FileAdapter : IFileAdapter
{
public FileStream Open(string fileName)
{
return System.Io.File.Open(fileName);
}
public string ReadLine(FileStream fileStream)
{
return File.Open(fileStream);
}
}
Now, as usual, you can mock the file system, as you would any other class, supplying the returned results. Remember - you are not testing Java's IO classes it is assumed that they work. You are only testing your classes (i.e. MyManager, in the example above).
Leave the tests that actually use the file system to your integration / acceptance tests.
Hope this helps,
Assaf.
I would prefer to abstract file system, so that my unit-test wouldn't require access to real file system. Of course, this abstraction layer must be tested with real file system, but this allow you to reduce dependency on it.
As for storing hidden files in SVN, I second artemb. You should create all files necessary to test in JUnit set up. Presumably, you should prefer setup per test method (#Before and #After). But if you encounter test slowness problems, have a look at #BeforeClass and #AfterClass. I consider they can be used with test suites too.
artemb's answer is correct, you can use #Before and #After to create and remove your structure for each test.
Here is some code I use to create a new directory with some files in it, it will create the directory in the systems temp dir, this is important because depending on the machine your tests will run on, you may will not be allowed to create files or dirs somewhere else. (I had to write this code to allow my tests to be executed on our linux integration machine...)
final String tempdir = System.getProperty("java.io.tmpdir");
final String dirname = Long.toHexString(System.currentTimeMillis());
final File dir = new File(tempdir, dirname);
dir.deleteOnExit();
dir.mkdir();
final String path = dir.getAbsolutePath();
assertTrue(dir.exists());
// pre condition, the directory is empty
assertTrue(dir.list().length == 0);
// create temp files in the directory
final int nbFiles = 3;
for (int i = 0; i < nbFiles; i++) {
(File.createTempFile("test", ".txt", dir)).deleteOnExit();
}
BTW you will have to know on what platform you run to be able to create hiden files...