I am currently writing a class which processes a log file, inserts some
data into the database, and then rotates the log file. I am doing
test-driven development and I was curious as to the best practices for
testing classes which manipulate the file system.
Rails tests have a transactional feature for testing database
manipulation such that changes made to the DB are reset after each test.
I was wondering if there was anything like this for the file system. It
would be great if the test could automatically reverse any file system
changes made during a test; I could imagine doing this via proxying
access to the File, FileUtils, and Dir classes. Has anything like this
been done? Or is there a better approach altogether?
For the record, I'm using Shoulda.
···
--
Posted via http://www.ruby-forum.com/.
You should use mock objects in place of file operations.
If you're using mocha, you can do things like
File.expects(:delete).with(file_name)
File.delete(file_name)
···
On Thu, Jan 29, 2009 at 10:37 PM, Chris Vincent <c.j.vincent@gmail.com>wrote:
I am currently writing a class which processes a log file, inserts some
data into the database, and then rotates the log file. I am doing
test-driven development and I was curious as to the best practices for
testing classes which manipulate the file system.
Rails tests have a transactional feature for testing database
manipulation such that changes made to the DB are reset after each test.
I was wondering if there was anything like this for the file system. It
would be great if the test could automatically reverse any file system
changes made during a test; I could imagine doing this via proxying
access to the File, FileUtils, and Dir classes. Has anything like this
been done? Or is there a better approach altogether?
For the record, I'm using Shoulda.
--
Posted via http://www.ruby-forum.com/\.
--
Andrew Timberlake
http://ramblingsonrails.com
http://www.linkedin.com/in/andrewtimberlake
"I have never let my schooling interfere with my education" - Mark Twain