Posts tagged with '.NET'

This is a repost that originally appeared on the Couchbase Blog: C# Tuples: New C# 7 language feature.

C# tuples are a new feature of C# 7. I’m going to show you the basics of how C# tuples work. I’m also going to mix in a little Couchbase to show tuples in action. However, if you don’t want to install Couchbase just to play around with tuples, don’t worry, you will still be able to follow along.

Note: If you’ve been using C# for a while, you might remember the Tuple Class that was introduced in .NET 4. That class still exists, but it is not the same thing as the new tuple feature of C#.

What are C# tuples?

A "tuple" is a name for a mathematical concept that is just a list of elements. In the LISP family of languages, coding is built almost entirely around the idea that everything is a list. C# once again borrows the kernel of an idea from the functional programming world and integrates it into a non-functional language. So, we get C# tuples (check out the original C# tuple proposal by Mads Torgersen for more details and background).

Remember anonymous types?

But, to make it simple, let’s consider something you may already be familiar with in C#, an anonymous type. To review, you can instantiate a new object without specifying a type:

var myObject = new { Foo = "bar", Baz = 123 };

Behind the scenes, there actually is a type that inherits from the base Object type, but generally speaking, we only deal with the object, not its type.

Additionally, I can’t return an anonymous type from a method, or pass an anonymous type as a parameter without losing the type information in the process.

private object GetAnonymousObject()
{
    return new {Foo = "bar", Baz = 123};
}

private void AnotherMethod()
{
    var obj = GetAnonymousObject();
    Console.WriteLine(obj.Foo); // compiler error :(
}

They are useful, certainly, but I generally refer to these as anonymous objects as I use them, for these reasons.

What’s this got to do with C# tuples?

I think of C# tuples as richer anonymous types. They are a way to create a "class" on the fly without actually defining a class. The syntax for tuples is to simply put parenthesis around a comma separated list of types and names. A tuple literal is just a comma separated list of literals also surrounded by parenthesis. For instance:

(string FirstName, string LastName) myTuple = ("Matt", "Groves");

Console.WriteLine(myTuple.FirstName); // no compiler error :)
Console.WriteLine(myTuple.LastName);  // no compiler error :)

Note: Right now I’m preferring PascalCase for tuple properties. I don’t know if that’s the official guideline or not, but it "feels" right to me.

C# tuples in action

I put tuples to work in a simple console app that interacts with Couchbase.

I created a BucketHelper class that is a very simple facade over the normal Couchbase IBucket. This class has two methods: one to get a document by key and return a tuple, and one to insert a tuple as a document.

public class BucketHelper
{
    private readonly IBucket _bucket;

    public BucketHelper(IBucket bucket)
    {
        _bucket = bucket;
    }

    public (string Key, T obj) GetTuple<T>(string key)
    {
        var doc = _bucket.Get<T>(key);
        return (doc.Id, doc.Value);
    }

    public void InsertTuple<T>((string Key, T obj) tuple)
    {
        _bucket.Insert(new Document<T>
        {
            Id = tuple.Key,
            Content = tuple.obj
        });
    }
}

To instantiate this helper, you just need to pass an IBucket into the constructor.

Tuple as a return type

You can then use the GetTuple method to get a document out of Couchbase as a tuple.

var bucketHelper = new BucketHelper(bucket);

(string key, Film film) fightClub = bucketHelper.GetTuple<Film>("film-001");

The tuple will consist of a string (the document key) and an object of whatever type you specify. The document content is JSON and will be serialized to a C# object by the .NET SDK.

Also, notice that the name of the tuple properties don’t have to match. I used obj in BucketHelper but I used film when I called GetTuple<Film>. The types do have to match, of course.

Tuple as a parameter type

I can also go the other way and pass a tuple as a parameter to InsertTuple.

string key = Guid.NewGuid().ToString();
Film randomFilm = GenerateRandomFilm();
bucketHelper.InsertTuple((key, randomFilm));

The GenerateRandomFilm method returns a Film object with some random-ish values (check out the GitHub source for details). A tuple of (string, Film) is passed to InsertTuple. The Couchbase .NET SDK takes it from there and inserts a document with the appropriate key/value.

Running the console app, you should get an output that looks something like this:

C# tuples sample console output

Note that the Couchbase .NET SDK at this time doesn’t have any direct tuple support, and it may not ever need it. This code is simply to help demonstrate C# tuples. I would not recommend using the BucketHelper as-is in production.

TUH-ple or TOO-ple?

I seem to remember my professor(s) pronouncing it as "TOO-ple", so that’s what I use. Like the hard-G / soft-G debate of "GIF", I’m sure there are those who think this debate is of the utmost importance and are convinced their pronunciation is the one true way. But, both are acceptable.

If you have questions about tuples, I’d be happy to help. You can also contact me at Twitter @mgroves or email me matthew.groves@couchbase.com.

If you have questions about the Couchbase .NET SDK that I used in this post, please ask away in the Couchbase .NET Forums. Also check out the Couchbase Developer Portal for more information on the .NET SDK and Couchbase in general.

This is a repost that originally appeared on the Couchbase Blog: ASP.NET with NoSQL Workshop.

I delivered an ASP.NET with NoSQL workshop at the recent Indy.Code() conference in Indianapolis. I had a lot of fun at this conference, and I recommend you go next year. If you were unable to attend, don’t worry, because I’ve got the next best thing for you: all the material that I used in my workshop.

ASP.NET Workshop in 4 parts

This workshop contained four main parts:

  • Install a NoSQL database (Couchbase Server)

  • Interact with Couchbase Server (using both the Web Console and the .NET (or .NET Core) SDK)

  • Create a RESTful API using ASP.NET (or ASP.NET Core) WebAPI

  • Consume the RESTful API with an Angular frontend

Try it yourself

If you’d like to try it yourself, the ASP.NET with NoSQL Workshop materials are available on GitHub. Each part of the workshop contains a PPT and PDF file for you to follow along. Also, the "completed" version of each workshop is available.

If you get stuck or have any questions, please ask away in the Couchbase .NET Forums. Also check out the Couchbase Developer Portal for more information on the .NET SDK and Couchbase in general.

You can also contact me at Twitter @mgroves.

This is a repost that originally appeared on the Couchbase Blog: Data structures with Couchbase and .NET (video).

In February, I wrote a blog about using data structures with .NET (and .NET Core): List, Queue, and Dictionary.

Now, I’ve created a video to show the same concepts in action.

How to use Couchbase Data Structures with .NET

The source code used in this video is available on GitHub. Note that the source code uses .NET Core, but this should work just the same in .NET.

Thanks for watching!

If you have any questions about Couchbase and .NET, please ask away in the Couchbase .NET Forums. Also check out the Couchbase Developer Portal for more information on the .NET SDK and Couchbase in general.

You can also contact me at Twitter @mgroves.

Bill Wagner is writing .NET Core documentation.

Show Notes:

Bill Wagner is on Twitter

Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.

This is a repost that originally appeared on the Couchbase Blog: Visual Studio Live Unit Testing: New to Visual Studio 2017.

Visual Studio 2017 was just officially released. It comes with a lot of new, great stuff, but one of my favorite new features is built-in Visual Studio Live Unit Testing (available in Visual Studio 2017 Enterprise, not yet available for .NET Core projects).

In this post, I’m going to show you how Visual Studio Live Unit Testing works, as well as some thoughts around using unit tests vs integration tests. You can follow along by getting the full source code for this Live Unit Testing example on GitHub.

Visual Studio Live Unit Testing with NUnit

NUnit is perhaps the most popular testing tool for C#/.NET developers. Visual Studio Live Unit Testing can also work with xUnit and MSTest, but for this post I’m going to just cover NUnit.

To use NUnit, you add it with NuGet, just as normal. To use Visual Studio Live Testing, you’ll also need to add the NUnit Test Adapter (Install-Package NUnite3TestAdapter).

Next, start Live Testing by clicking Test → Live Unit Testing → Start.

Start Visual Studio Live Unit Testing

Writing a Unit Test

We’ll need some unit tests to demonstrate. We could just do Assert.That(1, Is.EqualTo(1)), but where’s the fun in that? Let’s create a shopping cart class.

public class ShoppingCart
{
    public string UserName { get; set; }
    public DateTime LastUpdated { get; set; }
    public List<Item> Items { get; set; }
    public decimal Total
    {
        get { return Items.Sum(i => i.Price); }
    }
}

This shopping cart has a couple properties, and a collection of items in it. Notice the Total property. Astute readers may already notice some problems with it, but let’s start with a single, simple unit test to make sure it calculates a total.

[Test]
public void ShoppingCart_Total_Should_Sum_Up_the_Item_Prices()
{
    // arrange: create shopping cart with 2 items and figure out the expected total
    var item1 = new Item { Name = "Large Pepperoni Pizza", Price = 14.99M };
    var item2 = new Item { Name = "Cheese Sticks", Price = 4.99M };
    var expectedTotal = item1.Price + item2.Price;
    var cart = new ShoppingCart { Items = new List<Item> { item1, item2 } };

    // act: user the Total method on ShoppingCart
    var actualTotal = cart.Total;

    // assert: totals should match
    Assert.That(actualTotal, Is.EqualTo(expectedTotal));
}

If Live Unit Testing is turned on, then the test is being automatically run in the background by Visual Studio. You should see some green checkmarks appear.

Visual Studio Live Unit Testing in action

The green checkmarks will also appear wherever the code that is under test is covered.

Visual Studio Live Unit Testing code under test

With Visual Studio Live Unit Testing, you don’t have to stop to run the tests. As you are coding, the tests will run, and give you immediate feedback on whether your code is making tests fail (or whether you’ve written enough code to make your test pass).

Most of all, this will encourage you to write more tests.

What are Integration Tests?

When writing unit tests, you are meant to test a small piece of code on its own. For code that interacts with some external service (a web service, a database, a file system, etc), you often mock those pieces out, so that you can focus on the unit.

You may also write integration tests with NUnit. Integration tests that are meant to go beyond testing a single unit of code, and test that systems work together. Let’s write a method that writes a record to Couchbase Server. This test will use a real database, therefore we can consider it an integration test.

public void SaveShoppingCart(ShoppingCart cart)
{
    _bucket.Insert(new Document<ShoppingCart>
    {
        Id = Guid.NewGuid().ToString(),
        Content = cart
    });
}

This method should save a shopping cart to a document in Couchbase Server. To make sure it’s working, we can write an NUnit test.

[Test]
public void Repo_Can_Save_a_New_Shopping_Cart_to_Database()
{
    // arrange: create a shopping cart
    var cart = new ShoppingCart
    {
        UserName = "Matthew " + Guid.NewGuid().ToString(),
        LastUpdated = DateTime.Now
    };

    // act: save shopping cart to database
    Repo.SaveShoppingCart(cart);

    // assert: check that the cart was saved
    var cartBackOut = Repo.GetCartByUserName(cart.UserName);
    Assert.That(cartBackOut, Is.Not.Null);
    Assert.That(cartBackOut.UserName, Is.EqualTo(cart.UserName));
}

Note: To keep this post simple, I omitted some of the repository details, and test setup. You can view all of this in the GitHub repository.

Integration Tests with Visual Studio Live Unit Testing

Visual Studio Live Unit Testing will happily run this unit test. You may not want these types of tests to be running in the background automatically because:

  1. If you don’t have Couchbase Server installed, or a bucket created and indexed, then they will fail.

  2. If you have a lot of tests that rely on external components, they could slow down the tests (reading/writing documents in Couchbase is very fast, but setting up a Cluster object for each test or test fixture is not).

  3. These tests could add a lot of unnecessary junk test data to your database.

Excluding Integration Tests from Visual Studio Live Unit Testing

To exclude tests from Live Unit Testing, you can simply right-click on the test file and select "Exclude" from the context menu.

Exclude from Live Unit Testing

After this, none of the tests in that file will be executed by Live Unit Testing. You can also exclude an entire project. So, if you organize unit tests and integration tests into separate projects, then you are all set.

If you don’t organize them into separate projects, then this process could be a bit tedious. Further, the Include/Exclude information is a local setting that can’t (as of the time I’m writing this, and to the best of my knowledge) be committed to source control.

So, after asking about Live Testing exclusion on StackOverflow, I created an attribute that you can place on tests to exclude them from Live Testing.

public class IgnoreForLiveTesting : Attribute, ITestAction
{
    readonly string _ignoreReason;

    public IgnoreForLiveTesting(string ignoreReason = null)
    {
        _ignoreReason = ignoreReason;
    }

    public ActionTargets Targets { get; set; }

    public void AfterTest(ITest test) { }

    public void BeforeTest(ITest test)
    {
        var isLiveTesting = AppDomain.CurrentDomain.GetAssemblies()
            .Any(a => a.GetName().Name == "Microsoft.CodeAnalysis.LiveUnitTesting.Runtime");
        if (isLiveTesting)
            Assert.Ignore(_ignoreReason ?? "Ignoring this test");
    }
}

This attribute implements the ITestAction interface (which is kinda like Aspect-Oriented Programming/AOP for NUnit, but that’s a topic for a whole other blog post). It will check to see if it’s being run by a LiveUnitTesting process. If it is, it instructs NUnit to ignore the test.

Furthermore, I added an optional ignoreReason to the constructor, so that you can add a helpful note to other people on your team to explain why this test should not be run with Live Unit Testing. You can use it on an integration test like so:

[IgnoreForLiveTesting("Integration Test")]

Summary

I’m not terribly pleased with this method, as it’s NUnit specific, and it’s not quite exactly what I was hoping for with Visual Studio Live Unit Testing. But right now I think "the juice is worth the squeeze". Live Unit Testing is such a great feature for writing code, especially Test-Driven Development (TDD), that it’s worth it to have to write and use a special NUnit attribute.

By all means, if you know of a better way to achieve this, I want to know about it. Please leave a comment below or ping me on Twitter @mgroves.

If you have questions about the Couchbase code you saw in this post, I’d be happy to help. Or, you can check out the responsive and knowledgeable community on the Couchbase .NET SDK forum. If you want to learn more about Couchbase, check out the Couchbase Developer Portal.

Matthew D. Groves

About the Author

Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.

Latest Comments

Twitter