Should you avoid built in classes when testing?

Question

1.00/5 (1 vote)

See more:

I have a program that compares two files to see if they are changed. One file is in the form of a FileInfo and the other is a custom struct.

The problem is that I can't fake FileInfo, the only solution I can come up with is converting the FileInfo to something other (the struct I made). But this introduces more complexity that i potentially want to test as well, leading back to the original problem: I can't fake FileInfo. And what if I want to test something using other built in classes, should I convert everything that can't be faked to my own equivalents?

I feel like I'm missing something obvious here (other than test driven development)

Posted 7-Jul-15 3:14am

We are Orz

Add a Solution

Comments

Sergey Alexandrovich Kryukov 7-Jul-15 11:43am

First of all, it's all quite unclear, but the question is: if you convert something to you "own equivalents", untested, what would your testing really test? All you are talking about is just files. Why not testing everything together in native forms of things?
—SA

virusstorm 7-Jul-15 11:59am

I'm assuming you want to perform a unit test and need to be able to simulate a FileInfo class. To do this, you need use a mocking framework. I personally like to use Moq (available on NuGet). Take a look at this thread:

http://stackoverflow.com/questions/10177363/mock-concrete-fileinfo-object

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)