C#中的流利断言如何主张匿名类型
我们正在使用Fluent主张为.NET CORE 3.1 Web API进行测试驱动的开发,并使用Xunit进行相同的开发。
这就是我的控制器返回的。
{
"usersResult": [
{
"UserId": "1",
"UserName": "Foo"
},
{
"UserId": "2",
"UserName": "Boo"
}
]
}
在我的测试方法中,我想检查它是否返回对象,即我要在UserResult类型上断言,当我调试其显示“ userresult”的匿名类型时 ,所以我与应在:应该()的情况下指定哪种类型
[HttpGet]
public async Task<IActionResult> GetUsers()
{
Users us = new Users();
var us = await _service.GetUsers();
return Ok(new { usersResult = us });
}
public class Users
{
public string UserId{ get; set; }
public string UserName{ get; set; }
}
。
[Fact]
public async Task GetUsers_OnSuccess_ReturnsListOfUsers()
{
var sut = new UserController();
var result = await sut.GetUsers();
result.Should().BeOfType<OkObjectResult>();
var objectResult = (OkObjectResult)result;
objectResult.Value.Should().BeOfType<**WHAT_To_Specify**>();
}
We are trying the Test Driven Development using Fluent Assertions for our .Net core 3.1 Web API and using XUnit for the same.
This is what my controller returns.
{
"usersResult": [
{
"UserId": "1",
"UserName": "Foo"
},
{
"UserId": "2",
"UserName": "Boo"
}
]
}
In my test method, I want to check if it returns an object, i.e. I want to assert on the userResult Type, when I debug its showing anonymous type for "userResult"
, so I am confused to what type should I specify in : Should().BeOfType(??)
[HttpGet]
public async Task<IActionResult> GetUsers()
{
Users us = new Users();
var us = await _service.GetUsers();
return Ok(new { usersResult = us });
}
public class Users
{
public string UserId{ get; set; }
public string UserName{ get; set; }
}
// TestMethod :
[Fact]
public async Task GetUsers_OnSuccess_ReturnsListOfUsers()
{
var sut = new UserController();
var result = await sut.GetUsers();
result.Should().BeOfType<OkObjectResult>();
var objectResult = (OkObjectResult)result;
objectResult.Value.Should().BeOfType<**WHAT_To_Specify**>();
}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在TDD中,最好将关注和倾斜(依赖性反转原则)分开,
负责接收请求并将其发送到服务的控制器,因此内部没有任何逻辑。
在大多数情况下,我们使用单元测试来确保逻辑的平静效果良好。
它不建议在具有两个或多层抽象层的地方使用它,
您需要将SUT(正在测试的系统)与所需的抽象(如存储库)隔离。
例如:当您在项目中使用存储库模式并在服务中调用存储库方法时,最好使用模拟,假或存根来创建存储库接口的假实例
并从中返回您喜欢的结果。这就是我们所说的单元测试。
您试图进行的测试称为集成测试。
并且不建议在控制器和服务之间使用它。
我们通常使用它来确保数据库和项目之间的相互作用完全很好。
我建议忽略这部分,不要以这种方式进行测试。
但是,如果您想测试它:
最好使用具有从API到数据库的测试孔操作的SpecFlow使用行为测试(API测试)。
in TDD its better to apply separation of concern and DIP ( Dependency Inversion Principle) in your project ,
the Controller Responsible for Receiving Requests and Send them to the Services , so it doesn't have any logic inside .
in most situations we use unit testing to make sure a peace of logic working well.
its not recommended to use it in places which have two or more layers of abstraction ,
you need to isolate the SUT(System under Test)from required abstractions like repositories.
For Example : when you are using Repository Pattern in your project and call repository methods in your services , Its Better to use Mock , Fake or Stub to Create a fake instance of repository interface
and return your favorite result from it . this is what we call it unit test .
the test you are trying to have it is called Integration Testing .
and Its Not Recommended to use it between Controller and Service .
we usually use it to make sure the interaction between database and project is completely fine.
I Suggest to Ignore this part and don't test it in this way .
but if you want to test it :
its better to use Behavior Testing(API Testing) with specflow which is Test Hole Operation from API to Database .
您不应该直接测试控制器类。 You should create an in-memory test server and then invoke real HTTP requests like
You shouldn't directly test your controller classes. You should create an in-memory test server and then invoke real HTTP requests like this.