how can I write a JUnit test, that checks if a FileInputStream has been closed?
Consider the following code,
import java.io.FileInputStream;
class FileInputStreamDemo {
public static void main(String args[]) throws Exception {
FileInputStream fis = new FileInputStream(args[0]);
// Read and display data
int i;
while ((i = fis.read()) != -1) {
System.out.println(i);
}
fis.close();
}
}
I would like to write a test like this:
#Test
public void test() {
FileInputStreamDemo.main("file.txt");
// test here, if input stream to file is closed correctly
}
Although this code example doesn't make much sense, I would like to now how to write a JUnit test that checks if the FIS has been closed. (If possible: without even having a reference to the original FIS object)
You should create a separate class called MyFileReader which does the job of reading the file. You then create a class MyFileReaderTest which instantiates your new class and calls the methods in it to test that it behaves correctly. If you make fis a protected member of the MyFileReader class the test can access fis and verify it has been closed.
Instead of using FileInputStream you should use an interface like InputStream so that you can create a MockInputStream which doesn't really create a file but keeps track of whether close() was called on it. Then you can test for that in your test code.
Related
Is it not possible to append to an ObjectOutputStream?
I am trying to append to a list of objects. Following snippet is a function that is called whenever a job is finished.
FileOutputStream fos = new FileOutputStream
(preferences.getAppDataLocation() + "history" , true);
ObjectOutputStream out = new ObjectOutputStream(fos);
out.writeObject( new Stuff(stuff) );
out.close();
But when I try to read it I only get the first in the file.
Then I get java.io.StreamCorruptedException.
To read I am using
FileInputStream fis = new FileInputStream
( preferences.getAppDataLocation() + "history");
ObjectInputStream in = new ObjectInputStream(fis);
try{
while(true)
history.add((Stuff) in.readObject());
}catch( Exception e ) {
System.out.println( e.toString() );
}
I do not know how many objects will be present so I am reading while there are no exceptions. From what Google says this is not possible. I was wondering if anyone knows a way?
Here's the trick: subclass ObjectOutputStream and override the writeStreamHeader method:
public class AppendingObjectOutputStream extends ObjectOutputStream {
public AppendingObjectOutputStream(OutputStream out) throws IOException {
super(out);
}
#Override
protected void writeStreamHeader() throws IOException {
// do not write a header, but reset:
// this line added after another question
// showed a problem with the original
reset();
}
}
To use it, just check whether the history file exists or not and instantiate either this appendable stream (in case the file exists = we append = we don't want a header) or the original stream (in case the file does not exist = we need a header).
Edit
I wasn't happy with the first naming of the class. This one's better: it describes the 'what it's for' rather then the 'how it's done'
Edit
Changed the name once more, to clarify, that this stream is only for appending to an existing file. It can't be used to create a new file with object data.
Edit
Added a call to reset() after this question showed that the original version that just overrode writeStreamHeader to be a no-op could under some conditions create a stream that couldn't be read.
As the API says, the ObjectOutputStream constructor writes the serialization stream header to the underlying stream. And this header is expected to be only once, in the beginning of the file. So calling
new ObjectOutputStream(fos);
multiple times on the FileOutputStream that refers to the same file will write the header multiple times and corrupt the file.
Because of the precise format of the serialized file, appending will indeed corrupt it. You have to write all objects to the file as part of the same stream, or else it will crash when it reads the stream metadata when it's expecting an object.
You could read the Serialization Specification for more details, or (easier) read this thread where Roedy Green says basically what I just said.
The easiest way to avoid this problem is to keep the OutputStream open when you write the data, instead of closing it after each object. Calling reset() might be advisable to avoid a memory leak.
The alternative would be to read the file as a series of consecutive ObjectInputStreams as well. But this requires you to keep count how many bytes you read (this can be implementd with a FilterInputStream), then close the InputStream, open it again, skip that many bytes and only then wrap it in an ObjectInputStream().
I have extended the accepted solution to create a class that can be used for both appending and creating new file.
import java.io.DataOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
import java.io.OutputStream;
public class AppendableObjectOutputStream extends ObjectOutputStream {
private boolean append;
private boolean initialized;
private DataOutputStream dout;
protected AppendableObjectOutputStream(boolean append) throws IOException, SecurityException {
super();
this.append = append;
this.initialized = true;
}
public AppendableObjectOutputStream(OutputStream out, boolean append) throws IOException {
super(out);
this.append = append;
this.initialized = true;
this.dout = new DataOutputStream(out);
this.writeStreamHeader();
}
#Override
protected void writeStreamHeader() throws IOException {
if (!this.initialized || this.append) return;
if (dout != null) {
dout.writeShort(STREAM_MAGIC);
dout.writeShort(STREAM_VERSION);
}
}
}
This class can be used as a direct extended replacement for ObjectOutputStream.
We can use the class as follows:
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
public class ObjectWriter {
public static void main(String[] args) {
File file = new File("file.dat");
boolean append = file.exists(); // if file exists then append, otherwise create new
try (
FileOutputStream fout = new FileOutputStream(file, append);
AppendableObjectOutputStream oout = new AppendableObjectOutputStream(fout, append);
) {
oout.writeObject(...); // replace "..." with serializable object to be written
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
}
How about before each time you append an object, read and copying all the current data in the file and then overwrite all together to file.
I have an AWS Lambda implemented in java. The lambda generates a file, then writes it to the output, using the Base64 encoder. I'm trying to write a unit test for it, but it enters an infinite loop when the file is written.
What I'd like to do is capture what is written to the encodedStream in the unit test, write it to the temporary folder, and then compare the contents to the expected contents, but the test hangs until eventually an out of memory exception is thrown.
Lambda code
public class MyLambda implements RequestStreamHandler {
private static final Logger LOGGER = LogManager.getLogger(MyLambda.class);
#Override
public void handleRequest(#Nonnull InputStream inputStream, #Nonnull OutputStream outputStream, #Nonnull Context context) {
try (OutputStream encodedStream = Base64.getEncoder().wrap(outputStream);){
encodedStream.write("This is written to file".getBytes());
} catch (IOException e) {
LOGGER.info("IOException occurred ", e);
}
}
}
Unit test
public class MyLambdaTest {
#Rule
public TemporaryFolder temporaryFolder = new TemporaryFolder();
#Test
public void testRequest() throws IOException {
MyLambda myLambda = new MyLambda();
InputStream inputStream = mock(InputStream.class);
OutputStream mockOutputStream = mock(OutputStream.class);
Context mockContext = mock(Context.class);
doNothing().when(mockOutputStream).write(anyInt());
doNothing().when(mockOutputStream).write(any(byte[].class));
doNothing().when(mockOutputStream).write(any(byte[].class), anyInt(), anyInt());
myLambda.handleRequest(inputStream, mockOutputStream, mockContext);
FileUtils.writeByteArrayToFile(temporaryFolder.newFile(), <captured bytes>);
}
}
I have deployed the code to AWS, so I know it works, but I'd like to have a proper unit test written for it for future builds
Instead of mocking the OutputStream, you can create a ByteArrayOutputStream. It's basically just an array of bytes that implements OutputStream. And then you can verify the correct content was written with ByteArrayOutputSteam#toBytes(), or ByteArrayOutputStream#toString()
FileOutputStream fout =
new FileOutputStream(temporaryFolder.newFile("testout.txt"));
MyLambda myLambda = new MyLambda();
myLambda.handleRequest(null, fout, null);
fout.close();
Hi Joseph,
Please find my attempt above. I have used a real FileOutputStream.
I've a usecase where I'm creating an InputStream in one class & passing it to another. If I remove the finally block where I close the stream, it does not get detected in findbugs. Why is that?
Class A {
public static void methodA(InputStream is) {
// Do something.
// The stream is NOT closed.
}
}
Class B {
public void methodB(Sting filePath) {
FileInputStream fis = new FileInputStream(new File(filePath));
A.methodA(fis);
}
}
Ideally, findbugs should have detected that the stream is not closed in this use case. But, it doesn't & I'm curious to know why!
I am trying to store an OutputStream as a member of a class so that I can write to it from multiple methods. I put together this jUnit test to demonstrate the problem I have.
public class XmlStreamWriterTest {
private OutputStream outputStream;
#Before
public void setUp() throws Exception {
File file = new File("xmltester.xml");
this.outputStream = new FileOutputStream(file);
}
#After
public void tearDown() throws Exception {
this.outputStream.close();
}
//This doesn't work.
#Test
public void testOutputStream() throws Exception {
XMLOutputFactory xmlOutputFactory = XMLOutputFactory.newInstance();
XMLStreamWriter xmlStreamWriter = xmlOutputFactory.createXMLStreamWriter(this.outputStream);
xmlStreamWriter.writeStartElement("test");
xmlStreamWriter.writeCharacters("This is a test.");
xmlStreamWriter.writeEndElement();
xmlStreamWriter.flush();
}
//This works
#Test
public void testOutputStreamLocal() throws Exception {
File file = new File("xmltester2.xml");
OutputStream outputStreamLocal = new FileOutputStream(file);
XMLOutputFactory xmlOutputFactory = XMLOutputFactory.newInstance();
XMLStreamWriter xmlStreamWriter = xmlOutputFactory.createXMLStreamWriter(outputStreamLocal);
xmlStreamWriter.writeStartElement("test");
xmlStreamWriter.writeCharacters("This is a test.");
xmlStreamWriter.writeEndElement();
xmlStreamWriter.close();
}
}
Of the resulting files, only the second method pushes any values to the file. Do I have to pass the OutputStream to every method directly? Why doesn't the testOutputStream() method work?
I'm using the jrockit jdk 1.6.0_29, but I tried running on JDK 8 and it worked the same.
If you step through this test in a debugger and put a breakpoint on the "flush/close" (i.e. last) line in each test, when you step over it you can see that the file is written in both cases.
The problem is your setup method.
This is what is happening...
Setup is called, outputStream created (this will overwrite any existing file!!)
testOutputStream DOES work and outputs the file
Setup is called again, as an outputstream is created here, the file from the first test will be overwritten
The second test sets up another output stream
Basically, move the code out of your setup method into the first test case
I have class that gets GenericFile as input argument reads data and does some additional processing. I need to test it:
public class RealCardParser {
public static final Logger l = LoggerFactory.getLogger(RealCardParser.class);
#Handler
public ArrayList<String> handle(GenericFile genericFile) throws IOException {
ArrayList<String> strings = new ArrayList<String>();
FileInputStream fstream = new FileInputStream((File) genericFile.getFile());
DataInputStream in = new DataInputStream(fstream);
BufferedReader br = new BufferedReader(new InputStreamReader(in));
String strLine = br.readLine();//skip header
while ((strLine = br.readLine()) != null) {
l.info("handling in parser: {}", strLine);
strings.add(strLine);
}
br.close();
return strings;
}
}
The issue is with new FileInputStream. I can mock GenericFile but it is useless cause FileInputStream checks if file exists. I changed my class so:
public class RealCardParser {
public static final Logger l = LoggerFactory.getLogger(RealCardParser.class);
protected BufferedReader getBufferedReader(GenericFile genericFile) throws FileNotFoundException {
FileInputStream fstream = new FileInputStream((File) genericFile.getFile());
DataInputStream in = new DataInputStream(fstream);
return new BufferedReader(new InputStreamReader(in));
}
#Handler
public ArrayList<String> handle(GenericFile genericFile) throws IOException {
ArrayList<String> strings = new ArrayList<String>();
BufferedReader br = getBufferedReader(genericFile);
String strLine = br.readLine();//skip header
while ((strLine = br.readLine()) != null) {
l.info("handling in parser: {}", strLine);
strings.add(strLine);
}
br.close();
return strings;
}
}
So now I can override method getBufferedReader and test method handler:
#RunWith(MockitoJUnitRunner.class)
public class RealCardParserTest {
RealCardParser parser;
#Mock
GenericFile genericFile;
#Mock
BufferedReader bufferedReader;
#Mock
File file;
#Before
public void setUp() throws Exception {
parser = new RealCardParser() {
#Override
public BufferedReader getBufferedReader(GenericFile genericFile) throws FileNotFoundException {
return bufferedReader;
}
};
when(genericFile.getFile()).thenReturn(file);
when(bufferedReader.readLine()).thenReturn("header").thenReturn("1,2,3").thenReturn(null);
}
#Test
public void testParser() throws Exception {
parser.handle(genericFile);
//do some asserts
}
}
Handler method now is covered with tests, but I still have uncovered method getBufferedReader that leads to cobertura problems.
How to test method getBufferedReader or maybe there is another solution of the problem?
You can mock FileInputStream by using PowerMockRunner and PowerMockito. See the below code for mocking-
#RunWith(PowerMockRunner.class)
#PrepareForTest({
FileInputStream.class
})
public class A{
#Test
public void testFileInputStream ()
throws Exception
{
final FileInputStream fileInputStreamMock = PowerMockito.mock(FileInputStream.class);
PowerMockito.whenNew(FileInputStream.class).withArguments(Matchers.anyString())
.thenReturn(fileInputStreamMock);
//Call the actual method containing the new constructor of FileInputStream
}
}
Maybe this is a bad idea, but my first approach would have been creating an actual test-file rather than mocking the stream object.
One could argue that this would test the GenericFile class rather than the getBufferedReader method.
Maybe an acceptable way would be to return an actually existing test-file through the mocked GenericFile for testing the getBufferedReader?
I would first extract the creation of the Stream into a dependency. So your RealCardParser gets a StreamSource as a dependency.
Now you can take appart your problem:
for your current test provide a mock (or in this case I would prefer a fake) implementation returning a Stream constructed from a String.
Test the actual StreamSource with a real file, ensuring that it returns the correct content and what not.
I know this isn't the answer that you want.
The idea of unit testing is to make sure your logic is correct. Unit tests catch bugs where incorrect logic has been written. If a method contains no logic (that is, no branching, looping or exception handling), then it is uneconomical to unit test it. By that, I mean that a unit test costs money - time to write it, and time to maintain it. Most unit tests pay us back for that investment, either by finding bugs, or re-assuring us that there are no bugs in the domain of what is being tested.
But a unit test for your getBufferedReader method would not pay you back for our investment. It has a finite cost, but zero benefit, because there is no actual logic that can go wrong. Therefore, you should NOT write such a unit test. If your Cobertura settings or your organisational standards require the existence of such a unit test, then those settings or standards are WRONG and should be changed. Otherwise, your employer's money is being spent on something that has an infinite cost:benefit ratio.
I strongly recommend that your standards are changed so that you only write unit test for methods that contain branching, looping or exception handling.
When you are having this question. You are probably not following dependency inversion principle correctly. You should use InputStream whenever it's possible. If your write your FileInputStream adapter method like this:
class FileReader {
public InputStream readAsStream() {
return new FileInputStream("path/to/File.txt");
}
}
Then you can mock the method to return ByteArrayInputStream alternatively. This is much easier to deal with, because you only need to pass a string to the stream instead of dealing with the specific FileInputStream implementation.
If you are using mockito to mock, the sample goes like this:
FileReader fd = mock(FileReader());
String fileContent = ...;
ByteArrayInputStream bais = new ByteArrayInputStream(fileContent);
when(fd.readAsStream()).thenReturn(bais);