小编ris*_*shi的帖子

用于基于微服务架构的应用程序的存储库结构的更好方法？

例如，我通过 Microsoft 参考架构，即 github 存储库中的 eShopContainers [ https://github.com/dotnet-architecture/eShopOnContainers/tree/dev/src] 进行引用。但这带来了一些更复杂的动态工作环境，其中团队在各种 UI、微服务上工作，因此在一个存储库下的所有内容都使得合并/冲突等过程更加耗时。 一些团队成员希望拥有每个微服务在开发时在单独的存储库中进行更好的管理，然后在生产后导出到组存储库，即 BAU。感谢讨论利弊，以便为​​我们的环境做出更好的决定。

我有一个在 .net core 2.0 启动时启动的后台任务，从 backgroundservice 继承，实现了 StartAsync、StopAsync 和 ExecuteAsync。这个任务是根据一些业务逻辑定期更新数据库表中的一些数据。

虽然我可以将后台任务作为应用程序运行并使用日志、数据库检查和其他工具的帮助进行测试，但单元测试是否是测试后台任务所必需的？如果是这样，如何将任务注册为具有依赖项的服务并触发 start 和 stop 方法来断言实际与预期？欣赏一些基本的示例单元测试方法，用于测试基于 .net 核心 ihostedservice 后台任务的计时器。

这是我的基本测试开始，仅用于示例，但尚未完成。话虽如此，这只是一个想法，而不是确切的工作测试。这是需要社区帮助的地方。还可以添加更多断言，即 Assert.Verify()？

  [Fact]
        public async void Run_background_task_success()
        {
            //Arrange
            IServiceCollection services = new ServiceCollection();

            services.AddHostedService<BackgroundManagerTask>();

            var serviceProvider = services.BuildServiceProvider();

            var service = serviceProvider.GetService<IHostedService>() as BackgroundManagerTask;

            var isExecuted = false;
            if(await service.StartAsync(CancellationToken.None))
{
isExecuted = true;
}

            await Task.Delay(10000);
            Assert.True(isExecuted);

            await service.StopAsync(CancellationToken.None);
        }