Update tests' target framework

[martincostello]

Update the tests to target netcoreapp2.1 as well as update the .NET Core test SDK and xunit NuGet package references.

The xunit upgrade creates some code analysis warnings as xunit now ships with code analyzers, so they have also been fixed.

Originally part of #131.

[martincostello]

As an unintended side-effect of the runtime upgrade, some of the tests in ExpressionRewriterTests are now failing because the ToString() representations now include the airity of the type (so IEnumerable`1 instead of IEnumerable).

I wasn't sure the best way to fix these, so for now they're still broken. Will fix once there's a recommended approach.

[StanleyGoldman]

You can go ahead and change the strings in the ExpressionRewriterTests, they are there to prove we know what the expression being built is and to protect us from any unintended changes. Our asssumptions are still correct, it's just the string representation of them became more specific.

I'm going to let @grokys give you the final approval on this pull request as he is more savvy about .net core changes than I am. It is probably fine, but I'll let him make the call.

[martincostello]

Hmm - on closer inspection, I don't think that's going to be particularly maintainable.

For example, this is the actual string for one of the expressions now (from Licenses_Conditions_Select_ToDictionary), and with it also containing the names of anonymous types, they could be quite brittle to compiler-refactoring in the future.

"data => Convert(Select(data.get_Item(\"data\").get_Item(\"licenses\"), x => new <>f__AnonymousType2`2(Body = x.get_Item(\"body\").ToObject(), Items = Convert(Select(x.get_Item(\"items\"), i => new <>f__AnonymousType3`2(Key = i.get_Item(\"key\").ToObject(), Description = i.get_Item(\"description\").ToObject())).ToDictionary(d => d.Key, d => d.Description), IDictionary`2))).ToList(), IEnumerable`1)"

[martincostello]

So far all I can think of is asserting against the literal expected to be produced by the compiled query like this:

        [Fact]
        public void Licence_Conditions_Nested_Selects()
        {
            var expression = new Query()
                .Licenses
                .Select(x => new
                {
                    x.Body,
                    Items = x.Conditions.Select(i => i.Description).ToList(),
                });

            var actualQuery = expression.Compile().ToString();
            var expectedQuery = @"
query {
  licenses {
    body
    items: conditions {
      description
    }
  }
}
";

            Assert.Equal(expectedQuery.Trim(), actualQuery);
        }

[StanleyGoldman]

Sorry, I was not paying enough attention to what you were saying. These tests are tricky, I pushed the fix to them.

[StanleyGoldman]

So to explain the tests I just fixed, when we process a query we have to generate two things.

1. The actual graphql string we need to send to the connection
2. An expression that will process the JObject/JArray we get as a result of the queries execution

The ExpressionRewriterTests are showing that expression we generate to process the resultant data is correct.

All that said, just like you mentioned, there are tests that test the query we generate. Like this one...

octokit.graphql.net/Octokit.GraphQL.UnitTests/QueryBuilderTests.cs

Lines 9 to 44 in 0f34256

	[Fact]
	public void RepositoryOwner_Repository_Query()
	{
	var expected = @"query {
	repositoryOwner(login: ""foo"") {
	repository(name: ""bar"") {
	id
	name
	owner {
	login
	}
	isFork
	isPrivate
	}
	}
	}";
	var expression = new Query()
	.RepositoryOwner("foo")
	.Repository("bar")
	.Select(x => new
	{
	x.Id,
	x.Name,
	Owner = x.Owner.Select(o => new
	{
	o.Login
	}).Single(),
	x.IsFork,
	x.IsPrivate,
	});
	var query = expression.Compile();
	Assert.Equal(expected, query.ToString(), ignoreLineEndingDifferences: true);
	}

[martincostello]

Ah, that makes now.

I’d circled slightly around near that and almost stumbled across the fix myself, as VS was warning my about a redundant IEnumerable cast. I went the other way and just removed it, but that didn’t fix it.

[StanleyGoldman]

Yep, it would definitely be redundant for someone to actually write that in code.
Some of our tests are tricky, you'll get the hang of them.

[martincostello]

Some references snuck in when I extracted this from #131 - fixed now.

[StanleyGoldman]

Good catch.

[grokys]

Hi @martincostello - what was the reasoning behind updating the unit tests' framework?

[martincostello]

@grokys Two reasons:

1. I need 2.1 for HttpClient injection #131 to test usage with IHttpClientFactory.
2. I don't even have 1.1 installed on my laptop (because it's an old LTS release now), so I couldn't run the tests from Visual Studio and didn't really want to have to install it just to use an old version of the runtime.

[grokys]

@martincostello ok, thanks for explaining - they sound like good enough reasons to me!

[grokys]

Thanks a lot @martincostello - looks good to me.