Loading ...
Sorry, an error occurred while loading the content.

Re: [XP] How to unit test classes that interact directly with file system

Expand Messages
  • Sammy Larbi
    Sorry it took me so long, I ve gotten a bit behind. ... I was thinking you could inherit from and override the methods you need to test. Didn t know if that
    Message 1 of 12 , Jul 3, 2006
    • 0 Attachment
      Sorry it took me so long, I've gotten a bit behind.

      Tim Haughton wrote:
      >> Now, don't think I'm being a moron (even though I probably am). I'm
      >> unfamiliar here, so I want to ask "why not?" Is it forbidden? I would
      >> think (as long as it is not forbidden) that this would be the most
      >> preferable method.
      > Assuming we're using a run-of-the-mill mocking framework, we can only
      > mock virtuals and interfaces. From memory, the file system objects
      > don't have them.
      I was thinking you could inherit from and override the methods you need
      to test. Didn't know if that would work or not.
      >> Most definitely don't do that. But I wouldn't mind so much if the tests
      >> defined a file structure to test on (in fact, how else would you know
      >> your test is really passing or failing?).
      > I'm not sure what you mean here. Can you elaborate?
      I was simply saying rather than having a predefined file structure, you
      can have the tests define it. For instance, you wouldn't have a
      directory set up like "C:\app\test\someDirectory" where the unit tests
      called it. Rather, you would have (psuedocode):

      workingDir=createDir(currentDir + "\someDirectory");

      So it sets it up and tears it down, and you can move it anywhere you want.

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.