Daniel Cazzulino: Sharing assembly-level context across unit tests

Finally got around to implementing this for Xunit since I needed it for something (to be blogged soon too ;)). Copied from the project page. Enjoy!

Install-Package xunit.assemblyfixture

Provides shared state/fixture data across tests in the same assembly, following the design of class fixtures (rather than the more convoluted collection fixtures). To complement xUnit documentation style, I shamelessly copy its layout here.

Shared Context between Tests

Please read xUnit documentation on shared context and the various built-in options, which are:

To which this project adds:

  • Assembly Fixtures (shared object instances across multiple test classes within the same test assembly)

Assembly Fixtures

When to use: when you want to create a single assembly-level context
and share it among all tests in the assembly, and have it cleaned up after
all the tests in the assembly have finished.

Sometimes test context creation and cleanup can be very expensive. If you were
to run the creation and cleanup code during every test, it might make the tests
slower than you want. Sometimes, you just need to aggregate data across multiple
tests in multiple classes. You can use the assembly fixture feature of
xUnit.net [Assembly Fixtures]
to share a single object instance among all tests in a test assembly.

When using an assembly fixture, xUnit.net will ensure that the fixture instance
will be created before any of the tests using it have run, and once all the tests
have finished, it will clean up the fixture object by calling Dispose, if present.

To use class fixtures, you need to take the following steps:

  • Create the fixture class, and put the the startup code in the fixture
    class constructor.
  • If the fixture class needs to perform cleanup, implement IDisposable
    on the fixture class, and put the cleanup code in the Dispose() method.
  • Add IClassFixture<TFixture> to the test class.
  • If the test class needs access to the fixture instance, add it as a
    constructor argument, and it will be provided automatically.

Here is a simple example:

public class DatabaseFixture : IDisposable
{
    public DatabaseFixture()
    {
        Db = new SqlConnection("MyConnectionString");

        // ... initialize data in the test database ...
    }

    public void Dispose()
    {
        // ... clean up test data from the database ...
    }

    public SqlConnection Db { get; private set; }
}

public class MyDatabaseTests : IAssemblyFixture<DatabaseFixture>
{
    DatabaseFixture fixture;

    public MyDatabaseTests(DatabaseFixture fixture)
    {
        this.fixture = fixture;
    }

    // ... write tests, using fixture.Db to get access to the SQL Server ...
}

Just before the first test in the assembly to require the DatabaseFixture
is run, xUnit.net will create an instance of DatabaseFixture. Each subsequent
test will receive the same shared instance, passed to the constructor of
MyDatabaseTests, just like a static singleton, but with predictable cleanup
via IDisposable.

Important note: xUnit.net uses the presence of the interface
IAssemblyFixture<> to know that you want an assembly fixture to
be created and cleaned up. It will do this whether you take the instance of
the class as a constructor argument or not. Simiarly, if you add the constructor
argument but forget to add the interface, xUnit.net will let you know that it
does not know how to satisfy the constructor argument.

If you need multiple fixture objects, you can implement the interface as many
times as you want, and add constructor arguments for whichever of the fixture
object instances you need access to. The order of the constructor arguments
is unimportant.

Note that you cannot control the order that fixture objects are created, and
fixtures cannot take dependencies on other fixtures. If you have need to
control creation order and/or have dependencies between fixtures, you should
create a class which encapsulates the other two fixtures, so that it can
do the object creation itself.

Xamarin: Optimizing & Testing Libraries Leveraging Xamarin Test Cloud

The ability to combine Xamarin.UITest’s easy-to-use testing framework and Xamarin Test Cloud’s immense collection of real devices to automate and test mobile apps is an extremely powerful system, but did you know that you can also leverage Xamarin Test Cloud to test your .NET Libraries to ensure they are fully compatible across all of the […]

The post Optimizing & Testing Libraries Leveraging Xamarin Test Cloud appeared first on Xamarin Blog.

James Montemagno: DataBinding Settings in Xamarin.Forms

For nearly four years now I have been using my cross-platform settings plugin to save preferences across all the different platforms. Ever since I pushed it up to NuGet it has been extremely popular with over 18,000 installs! The plugin gives you a very simple way of saving out native settings from shared code. Usually, you will create a native UI for each platform and in the case of Android use the PreferenceActivity to automagically create a settings page from XML (which is magical), but what if you are using Xamarin.Forms and want to databind stuff up? This is the exact question I got over on StackOverflow. Of cource you can, let’s do it.

Given this Settings Class:


public static class Settings 
{

    private static ISettings AppSettings
    {
        get
        {
            return CrossSettings.Current;
        }
    }

    const string CountKey = "count";
    private static readonly int CountDefault = 0;


    public static int Count
    {
        get { return AppSettings.GetValueOrDefault<int>(CountKey, CountDefault); }
        set { AppSettings.AddOrUpdateValue<int>(CountKey, value); }
    }
}

Approach 1: Essentially you need to create a view model with a public property that you wish to data bind to and then call into settings from there and raise a property changed notification if the value changed. Your Settings.cs can stay the same but you will need to create the viewmodel such as:


public class MyViewModel : INotifyPropertyChanged
{

    public int Count
    {
        get { return Settings.Count; }
        set
        {
            if (Settings.Count == value)
                return;

            Settings.Count = value;
            OnPropertyChanged();
        }

    }

    private Command increase;
    public Command IncreaseCommand
    {
        get 
        { 
            return increase ?? (increase = new Command(() =>Count++));
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;

    public void OnPropertyChanged([CallerMemberName]string name = "")
    {
        var changed = PropertyChanged;
        if (changed == null)
            return;
        changed(this, new PropertyChangedEventArgs(name));
    }

}

Then you XAML will look like this inside your Content page:


<StackLayout Padding="25">
 <Button Text="Increase" Command="{Binding IncreaseCommand}"/>
 <Label Text="{Binding Count, StringFormat='The count is {0:F0}'}"/>
</StackLayout>

Make sure you set the BindingContext in the xaml.cs of the page:


public partial class MyPage : ContentPage
{
    public MyPage()
    {
        InitializeComponent();
        BindingContext = new MyViewModel();
    }
}

This actually isn’t too much code to actually implement as your ViewModel would have a BaseViewModel that implements INotifyPropertyChanged, so really you are just adding in


public int Count
{
    get { return Settings.Count; }
    set
    {
        if (Settings.Count == value)
            return;

        Settings.Count = value;
        OnPropertyChanged();
    }
}

Approach 2: More magical way

However, using the powers of C# and knowing how Databinding works you could first create a BaseViewModel that everything will use:


public class BaseViewModel : INotifyPropertyChanged
{
    public Settings Settings
    {
        get { return Settings.Current; }
    }
    public event PropertyChangedEventHandler PropertyChanged;

    public void OnPropertyChanged([CallerMemberName]string name = "")
    {
        var changed = PropertyChanged;
        if (changed == null)
            return;
        changed(this, new PropertyChangedEventArgs(name));
    }
}

Notice my reference to Settings.Current, we will need to implement that now as a singleton, but we will use our BaseViewModel so we don’t have to re-implement INotifyPropertyChanged:


public class Settings : BaseViewModel
{
    static ISettings AppSettings
    {
        get
        {
            return CrossSettings.Current;
        }
    }

    static Settings settings;
    public static Settings Current
    {
        get { return settings ?? (settings = new Settings()); }
    }

    const string CountKey = "count";
    static readonly int CountDefault = 0;

    public int Count
    {
        get
        { 
            return AppSettings.GetValueOrDefault<int>(CountKey, CountDefault); 
        }
        set
        { 
            if (AppSettings.AddOrUpdateValue<int>(CountKey, value))
                OnPropertyChanged();

        }
    }
}

Now of course we will still want to create a unique ViewModel that our XAML view will bind to:


public class MyViewModel : BaseViewModel
{
    private Command increase;
    public Command IncreaseCommand
    {
        get 
        { 
            return increase ?? (increase = new Command(() =>Settings.Count++));
        }
    }
}

Notice that we are now inheriting from BaseViewModel, which means our command can actually just increment Settings.HotTimeCount! But now we must adjust our Xaml just a bit as to what we are actually data binding to for our label:


<StackLayout Padding="25">
 <Button Text="Increase" Command="{Binding IncreaseCommand}"/>
 <Label BindingContext="{Binding Settings}" Text="{Binding Count, StringFormat='The count is {0:F0}'}"/>
</StackLayout>

Notice I am setting the BindingContext to our Settings, which is in our BaseViewModel for the Label, this must be done because that is where it is located now. And there you have it.

Xamarin: Be First To Try Our New Release Candidate

To keep pace with the rapid evolution of iOS, Android, and our own mobile innovations, we publish many updates to Xamarin over the course of the year. As Xamarin has grown, it has become increasingly important for our customers that every release of Xamarin be enterprise-grade: stable and high-quality. Today, we are instituting a new release […]

The post Be First To Try Our New Release Candidate appeared first on Xamarin Blog.

Johan Karlsson: FontAwesome using Xamarin Forms and iOS

This is the same post as the one for Android, except this one is for iOS. I didn’t really plan to write this one since the same info can be found https://blog.xamarin.com/custom-fonts-in-ios/. However, I got some comments about the previous post being incomplete, so I guess I have to complete myself.

Read this one first to get the background – http://www.johankarlsson.net/2015/09/fontawesome-using-xamarin-forms-and.html

I also moved the source to github since I might be adding stuff to it as I go along. Find it under johankson/awesome.

Here we go!

Download the font

Download the FontAwesome font and drop it in your Resource folder for the iOS project. Remember to change the “Copy to output directory” to “Always”, otherwise you’ll get a null reference exception.

Edit the info.plist file

In the root of your iOS project you’ll find a file called info.plist. We need to add stuff to it by editing the file using a text editor. If you simply double click it then Xamarin Studio (or Visual Studio) will open a GUI for it. We don’t want that. I recommend Sublime Text for all you text editing needs.
Add a key named UIAppFonts followed by an array. One entry in the array should point to the font, in this case the fontawesome.ttf. If you have multiple fonts just add more entries. Make sure you add the complete path if you add the font to a folder.

Edit the XAML

Add a FontFamily attribute to what ever control you’d like display an icon through. The FontFamily attribute will be ignored on Android so you still need the custom renderer covered in the last blog post. The XAML is from the file MyPage.Xaml in the Forms project.

The result

As expected, we see some FontAwesome icons. 

Extras

Remember that you can adjust the size and color by using the FontSize and TextColor properties. You can also add icons to buttons.
    <Button Text=&#xf041; FontSize=40 FontFamily=FontAwesome />

Summary

So you see that iOS is simpler than Android when it comes to using custom fonts. I also know at the time of writing I haven’t created a Windows Phone solution yet. I will as soon as time permits.

Xamarin: World Bank App Makes Complex Surveys Accessible Anywhere

The World Bank seeks to end extreme poverty and to push for greater equity. They have been providing loans to countries in development and transition since 1946, with more than $40 billion in loans supplied in 2014 alone. Supported by the 188 states of the United Nations and more than 12,000 staff in Washington D.C. […]

The post World Bank App Makes Complex Surveys Accessible Anywhere appeared first on Xamarin Blog.

Marcos Cobeña Morián: Colors in iOS: Same Value, Different Tonality

This entry was originally written at Plain Concepts’ Xamarin Team Blog. While working on a native Xamarin.iOS app, I noticed a difference between the same color applied through source code to the navigation bar and through Interface Builder to the background of a scroll view. There was a small difference between both colors’ tonality, although […]

Xamarin: Free Back-to-School Xamarin University Lectures

As summer turns to fall and school is back in session, Xamarin and Xamarin University would also like to help kickstart your mobile app development. Xamarin University subscribers now have access to over ?60 live online classes, covering everything from an Introduction to Xamarin and Xamarin.Forms all the way to advanced memory management and performance […]

The post Free Back-to-School Xamarin University Lectures appeared first on Xamarin Blog.

Adam J Wolf: Weekly Xamarin Newsletter Issue #60

UI Design with Xamarin.Forms Please join me (Adam) for my guest lecture at Xamarin University. Free Xamarin University Lightning Lectures Check out the Xamarin University Lightning Lectures from experts on common challenges in app development. Creating a Native View from a Xamarin.Forms View Michael Ridland gets jumpy and flips between native to Xamarin.Forms views. Testing Xamarin Apps: […]

The post Weekly Xamarin Newsletter Issue #60 appeared first on Syntax is my UI.