Winnie Tu

Visual Studio for Mac is a decent Integrated Development Environment (IDE) for writing .NET on a Mac. One area in which it has trouble is authenticating against a private NuGet feed. (For example, your company might host some common internal libraries). Attempting to configure a private NuGet feed using the Visual Studio for Mac IDE results in an endless authorization failure loop. See:

1. https://developercommunity.visualstudio.com/content/problem/270269/vs-for-mac-repeatedly-ask-for-credentials-when-upd.html
2. https://developercommunity.visualstudio.com/content/problem/120242/nuget-will-not-work-with-private-repos-401-errors.html

The solution is hidden away in a Microsoft document. In short, you must use NuGet V2 Application Programming Interface (API) feeds and a personal access token when accessing private NuGet feeds on a Mac.

First, select security from your Visual Studio online portal.

Then, you want to create a new Personal Access Token (PAT) with read-only packaging scope.

With your PAT, open a terminal and run the following command:

$ nuget sources add -name {your feed name} -source {your feed URL} 
-username {anything} -password {your PAT}

Make sure your feed URL is using NuGet V2. For example:

• Nuget v3 url: https://mynugeturl.org/nuget/v3/index.json
• Nuget v2 url: https://mynugeturl.org/nuget/v2

Now, after restarting Visual Studio, you’ll be able to restore packages from your private NuGet feed. Voila!

Integration tests need to be reliable. If you’re hitting your actual identity provider with an [Authorize] attribute, your tests will fail if that server ever goes down or makes backwards-incompatible changes. The purpose of an integration test in ASP.NET is to test your application pipeline; not the availability of an external server. Here’s how to bypass the [Authorize] attribute and inject your own claims for use in integration tests.

Normally, OAuth (json web token) authentication is implemented like this:

Startup.cs

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
                    .AddJwtBearer(options =>
                    {
                        options.Authority = MyAuthority;
                        options.Audience = MyAudience;
                    });

The trick to bypassing [Authorize] (and eventually injecting mocks) is to have override-able startup. I break up ConfigureServices into 3 sections: ConfigureAuth, ConfigureAppInsights, and ConfigureDependencies.

        /// 

        /// Configures authentication for the web app.  This is abstracted out 
        /// so that we can override the authentication middleware for an
        /// integration test, and thus, don't have a dependency on the
        /// identity server for the test.
        /// 
        protected virtual void ConfigureAuth(IServiceCollection services)
        {

        /// 

        /// Configures app insights for the web app.  Under test, we probably
        /// don't want real telemtery, so provide the option to turn it off.
        /// 
        protected virtual void ConfigureAppInsights(IServiceCollection services)
        {

        /// 

        /// Configures dependencies for the web app.  Under test, we likely
        /// want to use mocks, so this provides a convenient way to register
        /// different implementations.  Additionally or alternatively, calling
        /// services.addSingleton multiple times, when resolved, returns the
        /// last registered instance.
        /// 
        protected virtual void ConfigureDependencies(IServiceCollection services)
        {

        /// 

        /// Set up dependency injection, configuration bindings, etc.
        /// 
        public void ConfigureServices(IServiceCollection services)
        {
            this.ConfigureAuth(services);
            this.ConfigureAppInsights(services);
            this.ConfigureDependencies(services);

Then we need to write custom authentication middleware that will pass any authentication attempt and inject any claims we care about. Here’s the source for a “LocalAuthHandler” that injects a custom UserId claim.

https://gist.github.com/michaeltnguyen/718f801fba2fdf370e2e8c5a5e763e08

Now we need to make the asp net core authentication middleware use our custom auth handler.

        /// 

        /// For instrumented tests, causes the authorization middleware to
        /// bypass identity server and use the LocalAuthenticationHandler to
        /// authorize requests and inject a default company id claim.
        /// 
        public static AuthenticationBuilder AddLocalAuthentication(this IServiceCollection services)
        {
            return services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = LocalAuthenticationHandler.AuthScheme;
                options.DefaultChallengeScheme = LocalAuthenticationHandler.AuthScheme;
            }).AddScheme(
                LocalAuthenticationHandler.AuthScheme, _ => { });
        }

And here’s what an overridden startup might look like:

https://gist.github.com/michaeltnguyen/f4f36e1d92661b60fa1183bc5cb8760b

And now you can write integration tests that run through the whole http application pipeline.

One problem here is that the controller is still hitting the actual database, so there’s still an external dependency that can cause the test to fail. (mocks to the rescue!) We added a ConfigureDependencies method to our startup class, so now we have a way to inject mocks crafted specifically for the integration tests.

        protected override void ConfigureDependencies(IServiceCollection services)
        {
            services.AddSingleton(new Mock(MockBehavior.Strict).Object);
        }

Moq provides a method Mock.Get(T object) to retrieve the underlying mock. We use this extension method just for syntactic sugar

        /// 

        /// Retrieves a Mocked service for an integration test.  The type
        /// must be registered in LocalAuthStartup.ConfigureDependencies, or
        /// this call will throw an exception.
        /// 
        /// The mock service.
        public static Mock GetMockService(this IServiceProvider provider)
            where T : class
        {
            return Mock.Get(provider.GetService());
        }

So a full blown integration test with local authentication and injected database mocks looks like:

    protected IServiceProvider ServiceProvider { get; }

    protected HttpClient Client { get; }

    public LocalAuthControllerTest()
    {
        var webhost = new WebHostBuilder().UseStartup();
        var server = new TestServer(webhost);

        Client = server.CreateClient();
        ServiceProvider = server.Host.Services;
    }

[Fact]
        public async Task TestClaimedQuantityReport_ReturnsExpectedJson()
        {
            var dbManager = ServiceProvider.GetMockService();
            // set up mock here
            var result = await Client.GetAsync("/api/v1/employee?name=bob");
            var body = await result.Content.ReadAsStringAsync();
            var expectedResponse = File.ReadAllText("Responses/employees.json");

            Assert.Equal(HttpStatusCode.OK, result.StatusCode);
            Assert.True(JToken.DeepEquals(JToken.Parse(body), JToken.Parse(expectedResponse)));
            
            dbManager.VerifyAll();
        }

Tada! Now you have 100% reliable integration tests that run through the entire HTTP application pipeline without hitting network at all!

Content Providers are one of the four primary components of an Android application. If you’re an Android developer, you’re probably more familiar with the other three: Activity, Service, Broadcast Receiver). Content Providers are used for sharing data between applications. If you’re querying information about the user’s contacts, that comes from the Contacts Provider. If you’re picking an image from the user’s gallery, you’re getting a Content URI back from a separate Content Provider.

A Content Resolver is used to resolve that Content URI into useful information: a cursor containing contact information or an input stream representing a gallery image, e.g., via contentResolver.query(Uri) or contentResolver.openInputStream(Uri).

When testing an Android application, it can be helpful to use a mock Content Resolver instead of the real thing — e.g., to simulate contacts or gallery images on the device without actually adding them. This is doubly useful when testing on an emulator, which does not come preloaded with any contacts or images.

This is quite challenging for a few reasons (and also assumes that you are familiar with Dagger2 and Mockito):

Content Resolvers are acquired via context.getContentResolver(). This means that in order for your activity/service/broadcast receiver to use a mock, you have to have dependency injection set up. In addition, you can never call getContentResolver(), because this will always return the system’s actual Content Resolver.
Content Resolver methods are final, which means they cannot be mocked. Instead, we have to use a mock content resolver, which requires a bit of additional setup. (Content Resolvers are responsible for routing calls between the various Content Providers on the system, and so a mock Content Resolver needs to define a routing map of its own.)
You might also be using CursorLoader to perform queries asynchronously and to observe content URIs. Behind the scenes, CursorLoader calls context.getContentResolver(), which, as explained above, bypasses any mock that you’ve created.

With that disclaimer out of the way, here’s how create and use a mock content resolver for testing:

Write a Dagger Content Provider module. In production, the actual Content Resolver is used, but this provides us the flexibility to inject a mock under test.

@Module
public final class ContentProviderModule {

  @Provides
  ContentResolver provideContentResolver(Context context) {
    return context.getContentResolver();
  }
}

For the test, write a mock Content Resolver. There are a few tricks involved here.

First, a mock Content Provider must be written. (Remember, a Content Resolver is responsible for routing between one or more Content Providers. So in order to use mock Content Resolver, we must also have some mock Content Providers).

Second, Content Providers have some internal workings (such as the Transport class used for IPC) which still need to work with our mock. So we can either subclass Content Provider for each test (which is annoying), or we can use Mockito and a Delegating wrapper to ensure that the transport mechanisms are intact (which is better).

public class MockContentProviderWrapper extends ContentProvider {

private final ContentProvider mMockProvider;

public MockContentProviderWrapper(ContentProvider mock, String authority, Context context) {
mMockProvider = mock;
ProviderInfo info = new ProviderInfo();
info.authority = authority;
attachInfo(context, info);
}

@Override
public boolean onCreate() {
return false;
}

@Nullable
@Override
public Cursor query(@NonNull Uri uri, @Nullable String[] projection, @Nullable String selection,
@Nullable String[] selectionArgs, @Nullable String sortOrder) {
return mMockProvider.query(uri, projection, selection, selectionArgs, sortOrder);
}
}

Now we can use Mockito and inject a mock Content Resolver.

@Module
class MockContentProviderModule {

@Singleton
@Provides
ContentResolver provideContentResolver(ContentProvider provider, Context context) {
MockContentResolver mockResolver = new MockContentResolver();
MockContentProviderWrapper wrapper = new MockContentProviderWrapper(provider,
MyContract.CONTENT_AUTHORITY, context);
mockResolver.addProvider(MyContract.CONTENT_AUTHORITY, wrapper);
return mockResolver;
}

@Singleton
@Provides
ContentProvider provideMyProvider() {
return mock(ContentProvider.class);
}

And your test might look like this:

@Test
public void ensureEmptyView_visibleWhenNoData() {
when(mMockProvider.query(…))
.thenReturn(new MatrixCursor(new String[0]));

mTestRule.launchActivity(new Intent());

onView(withId(R.id.my_empty_view)).check(ViewAssertions.matches(
withEffectiveVisibility(ViewMatchers.Visibility.VISIBLE)));
}

If you’re using CursorLoader, you need to take an additional step. Because CursorLoader calls context.getContentResolver() and we can’t easily modify that class, we need to use a Context Wrapper whose getContentResolver() method returns our mock. This is left as an exercise for the reader.

Phew! That is a ton of work just to be able to write tests. We recommend this technique only if you have to interact with system-level Content Providers (such as the Contacts Provider). If you’re writing your own Content Providers and don’t have to share data with other apps, we recommend taking a look at the new Android architecture components, like Room.