C# – Unit Testing RIA Services

Agree with ChuckJ - generally the DomainContext forms part of a view model. For example, say I had a search page that allowed searching against a product catalog. Here is how I'd structure things:

On the server:

class Catalog : DomainService {
    IQueryable<Product> GetProducts(string keyword) { ... }
}

The generated DomainContext:

class Catalog : DomainContext {
    EntityList<Product> Products { get; }
    void LoadProducts(string keyword);
}

The view model I would write:

class SearchViewModel {
    Catalog _catalog = new Catalog();

    public IEnumerable<Product> Results {
        get { return _catalog.Products; }
    }

    public void Search(string keyword) {
        _catalog.Products.Clear();
        _catalog.LoadProducts(keyword);
    }
}

And then finally in my xaml, I'd set my UserControl's DataContext to be an instance of SearchViewModel, and bind an ItemsControl to the Results property. I'd use the ViewModel pattern of your choice to bind a button click to Search (which is effectively a command that SearchViewModel exposes). I personally like something that I have working with Silverlight.FX as in:

<Button Content="Search"
  fxui:Interaction.ClickAction="$model.Search(keywordTextBox.Text)" />

and as initially shown here.

As Chuck mentions I might indeed have other state in my view model, for example, the SelectedProduct that might be two-way bound to the SelectedItem of a ListBox in my xaml, and then bind the same SelectedProduct as the DataContext of a DataForm to show details of a selected product.

Hope that helps! I'll be blogging about this some more on my blog soon.

In your unit test, instance s needs to have a stubbed out implementation of _DataContext. When the Go method is called, and it calls: _DataContext.Employees.Add(e); _DataContext.SubmitChanges(); it will call into your stub. The stub should then record the fact that an employee got added and changes were submitted.

After the call to Go, you should query the stub to ensure that the new employee got added, and call to SubmitChanges occurred.

As a secondary note: I don't really agree with the last part of the other answer in that you should not care whether Go calls various methods of _DataContext. It is true that you're not concerned about testing _DataContext methods here, but the unit test for Go needs to ensure that the Go method is calling the _DataContext methods properly. The rationale is that every line of the Go method should be testable. If you didn't do this verification, then you could remove the calls to _DataContext method, breaking the code, but the unit test wouldn't catch it. This would break Bob Martin's the "three rules of TDD" principle.