We are going to implement a small java application with BDD, which reads an MS excel sheet using POI of apache.org and prints some text based on that excel to the STDOUT. We agreed that the simplest solution would be to create a test.xls for each BDD test case.

There was another idea, which is that we should mock the POI library calls and expectations for testing. The reasoning behind this idea is that we don't want to test the POI, and waste test time on using it in every test case. Additionally file access can be tricky on different operating systems.

So although there are certainly times when you want mock a subsystem because it is slow, proper mocking is identifying that slow system as something that needs architectural separation, so you would develop interfaces that properly represent your interaction with that slow system, and mock the behavior there. Then you would have another category of tests that test implementations of those interfaces that actually interact with the slow resources to make sure that that code works.

In terms of how this applies to POI, there may or may not be good justification to mock out an abstraction to POI. It depends on the scope of the project. To me, I would do it if I felt the project may need a different spreadsheet solution over the long haul.

I would certainly not mock out the actual POI classes, as the first link above makes abundantly clear how much pain can be involved in that approach.