Question

I am learning wpf. I am trying to utilize tdd practices with wpf. I have the following code in one of my viewmodels that saves data from a control into an xml file –

void saveStr()
        {
            string source = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + @"\Data\Connections.xml";

            DataGrid dg = FindChildViewItems.FindChild<DataGrid>(Application.Current.MainWindow, "MyDataGrid");
            List<XmlSettings> list = new List<XmlSettings>();

            foreach (var i in dg.Items)
            {
                if(i.GetType().ToString() == "MyProject.Configuration.XmlSettings")
                {
                    list.Add((XmlSettings)i);
                }
            }

            saveXml.Save(source, list);   
        }

The FindChildViewItems simply uses the visualtreehelper and dependency objects to find child items from the view (adapted from a post here).

My question is whether that adheres to tdd patterns since it has a dependency on the view when I am looking back to the view to get the contents of that particular control.

Is there another way to get the information from the datagrid on the view so that the contained data could be saved to an xml file.
I hope that makes sense……

Thanks for any thoughts.

Answer 1

Well, it looks like you’re breaking several patterns here. It’s definitely going to be very difficult to test.

Perhaps I can help you smooth out your structure a bit to make it more testable.

First, your viewmodel should not be saving state to a file! Your viewmodel should update the model whenever the user changes data in one of the datagrids, and nothing else. Use two-way databinding to allow your viewmodel to know when the view changes.

Persisting state to a file should be done in a different part of the program, possibly by a standalone command object, possibly in an event (alot of where this should occur depends on your program structure, and I can only guess at that). Regardless of where it occurs, it should be outside both your viewmodel and your model, and it should use your model to obtain the data it writes to a file.

After some minor tweaks to your method to account for this, it should be totally testable. Give it a stubbed model object (preferrably a class that only has user config settings) and let it go to town with your fake data.

Testing writing the file then becomes your biggest issue. Difficult to automate.

But testable.