Application: artemutin

[artemutin]

Hello. My name is Artem. I am an undergraduate student from Russia. I have some basic knowledge of C++ and Qt and have some amount of free time, which I want to spend for renovating my favorite game. I've already made some not-complicated tasks from bugtracker in order to get familiar with project.
To be honest , I am very interested in this particular bug/feature, cause it is the only block my favorite mod from starting with OpenMW. The branch with realization is already on hold in pull requests, and Scrawl had mentioned there, that there is need in some unit tests before merging to master. So, I would like, to suggest my help with those tests.

[scrawl]

Hi! Your help is welcomed. I have a few ideas for the tests. Will post a write up tomorrow.

[scrawl]

Sorry for the delay, here are my ideas:

Tests should cover the functionality of openmw/mwworld/store.{hpp|cpp}. At the very least we should test:
- overwriting records from a parent content file (various record types)
- deleting records from a parent content file (various record types)
- dialogue merging
- ESM::Cell merging

To set up a test, we can use the vanilla Morrowind game files as a test suite, or create our own minimal esm/esp test files. Problem with vanilla files is that they're not free, so can't be used by Travis-CI automated testing. The other problem is there are many different versions of these files, so it is possible that two people having different versions of the game would obtain different unit test results. So creating our own test files would be the preferred option. However in the case of a complex feature (dialogue merging) it should also be possible to work with the vanilla files, since it is difficult to construct a complete test case there.

As for creating our own test files, there are two implementation options. Personally I would tend towards option 2.
1. Create .esm/.esp files and place them in the repository. Easy to create with TES-CS or OpenCS, but harder to maintain because esm/esps are binary files - can't diff, can't easily view it.
2. Construct the test case directly in code (i.e. construct records instead of reading them from file). This way the test cases are in plain text.

Any other details not mentioned here I will leave up to the implementor. Hope that makes sense.