wpf and tdd patterns

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.G开发者_JS百科etExecutingAssembly().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.

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.

Ideally, if you would like to do proper TDD (Test Driven Development), you should try to use MVVM Design Pattern. It separates View from the ViewModel, thus making the ViewModel and Model easily testable.

if you have used MVVM in the above example, your Model would have save() method in it and then you would call it from VM. That way you can easily test your Model to make it saves.

And later on you can also test your VM, to make sure when you call SaveCommand it calls your Model's method. let me know if you need further info (google for MVVM if you havent heard about it before)