0

I've created an app for Windows 8 metro (aka WinRT) in Visual Studio 2013. I'm saving user data by serializing to XML using DataContractSerializer. I've also added a Unit Test Project for unit testing. I'd like to test saving/loading from XML. It works just fine in my app, and I can browse to the "LocalState" folder and verify that the XML contains the correct data. However, the unit test method doesn't seem to create any XML file like the main app, despite claiming to have "passed".

Does the unit test store its data somewhere else? How can I actually get to the XML file? Ideally I'd like to use the unit test to also generate large data sets and then load them in the main app, so simply saving/loading/checking for equality is not enough.

Here's the code I"m using to save data, which again works fine in the main app.

string localData = ObjectSerializer<myObject>.Serialize(_myObject);

            if (!string.IsNullOrEmpty(localData))
            {
                StorageFile localFile = await ApplicationData.Current.LocalFolder.CreateFileAsync("Data.xml", CreationCollisionOption.ReplaceExisting);
                await FileIO.WriteTextAsync(localFile, localData);
            }
7200rpm
  • 548
  • 1
  • 4
  • 14
  • There is no universal "unit test" thing - so unless you post code of your test there is absolutely no way to figure out what is wrong with your test. – Alexei Levenkov Apr 14 '14 at 02:23
  • You probably heading towards the wrong path interms of creating Unit Tests. It has nothing to do with browsing folders, reading from discs, and storing large set of data. – Spock Apr 14 '14 at 02:44

2 Answers2

0

The unit test project may be creating it's own (temporary, hidden) package in AppData\Local\Packages -- mine is. I use a two-step approach, mentioned in MSTest - DeploymentItem attribute unavailable on windows store test project

My data is in a sub folder of the unit test project, e.g. SMEPS_SM_SealBeach_Test, and I want this folder and all its files in my apps local folder. The files are marked copy-always.

First, use Build Events post-build, like so:

if not exist "$(TargetDir)AppX" mkdir "$(TargetDir)AppX"
if not exist "$(TargetDir)AppX\SMEPS_SM_SealBeach_Test" mkdir "$(TargetDir)AppX\SMEPS_SM_SealBeach_Test"
copy /Y "$(TargetDir)SMEPS_SM_SealBeach_Test\*.*" "$(TargetDir)AppX\SMEPS_SM_SealBeach_Test\"

This gets your data into Appx.

Then, at run-time, copy the data from Appx to the app local folder:

    [TestInitialize]
    async public Task TestDatabaseInitilize()
    {
        //manually copied data from 
        var site = "SMEPS_SM_SealBeach_Test";
        var appx = Package.Current.InstalledLocation;
        var reposTestFolder = await appx.GetFolderAsync(site);
        var testFiles = await reposTestFolder.GetFilesAsync();

        var localfolder = ApplicationData.Current.LocalFolder;
        var reposFolder = await localfolder.CreateFolderAsync(site, CreationCollisionOption.OpenIfExists);
        foreach (var file in testFiles)
        {
            await file.CopyAsync(reposFolder);
        }
    }

Now the app has SMEPS_SM_SealBeach_Test folder and all its data ready to use for testing.

Community
  • 1
  • 1
Jon B
  • 352
  • 2
  • 9
-1

I think, you should abstract out an interface from this functionality, allowing you to unit test the rest of your app without having to verify manually if the file has really been created on your disk.

Then by mocking or faking it, you'll just have to check if the interface method has been called with the good parameter.

public interface ILocalDataService {
  Task SaveToLocal(string localData, string filename)
  }

For further tests, if you need to read those local data, add a load method to this interface. Then by mocking it, you'll be able to make this method returns anything you want, even corrupted data :-)

Loul G.
  • 997
  • 13
  • 27