views:

49

answers:

1

Hi all,

I'm currently in the early stages of designing a system that will end up having lots of tests. The application will be handling various XML data, and knowing the type of classes/functions that will go into this, I know that many tests (we're talking 100+) will need to load small XML documents that will then be used to test the program functionality. These test XML documents will be 10 - 30 lines, on average.

Now, I want to store each XML test doc in its own file, for easier tweaking etc. Also, C++ string escaping rules make embedding XML directly into source code a painful process. If this was being written in Python, I'd simply use those multi-line """ comments and be done with it.

I can certainly read these XML files from disk on every test start, but that will make the tests slow as hell. Hundreds of tests, all hitting the disk at basically the same time? That can't be pretty. I'd like to have the files compiled into the test application (I'm using google mock + google test).

Normally, I'd use the Qt Resource System, but this project will not be using Qt. I certainly don't want to introduce such a large dependency even for the test app.

The other option that pops into mind is using xxd -i, but the application and the entire build system need to be cross-platform, and there's no xxd for Windows. Also, it's not the most elegant solution...

Does anyone have a good idea how to handle this problem?

+2  A: 

isn't it a case of the dreaded early optimisation?

"Hundreds of files" seems like a trivial task to me.

Just test it first, then optimise when you'll need it

Eric
A part of me thinks you may be right...
Lucas