Is this controller untestable?
up vote
0
down vote
favorite
In its present state I dont think I can test it because of the dependencies on user authentication (user.identity) and route data (RouteData.Values), original plan was to check if it was returning a view. Should I try to mock/fake these values or not be testing a controller like this in first place?
public IActionResult Index()
BlogHomeVM vm = new BlogHomeVM();
int skip = int.TryParse((string)this.RouteData.Values["skip"], out skip) ? skip : 0;
int showPosts = 3;
vm.PageTitle = "Async and wait";
vm.totalPosts = _context.Posts.Where(y => y.PublishedFrom <= DateTime.Now).Count();
vm.Posts = _context.Posts
.Where(y => y.PublishedFrom <= DateTime.Now .net unit-testing
asked Nov 9 at 10:58
CerIs
13418
add a comment |
up vote
0
down vote
favorite
In its present state I dont think I can test it because of the dependencies on user authentication (user.identity) and route data (RouteData.Values), original plan was to check if it was returning a view. Should I try to mock/fake these values or not be testing a controller like this in first place?
public IActionResult Index()
BlogHomeVM vm = new BlogHomeVM();
int skip = int.TryParse((string)this.RouteData.Values["skip"], out skip) ? skip : 0;
int showPosts = 3;
vm.PageTitle = "Async and wait";
vm.totalPosts = _context.Posts.Where(y => y.PublishedFrom <= DateTime.Now).Count();
vm.Posts = _context.Posts
.Where(y => y.PublishedFrom <= DateTime.Now .net unit-testing
asked Nov 9 at 10:58
CerIs
13418
1
You question is basically "should I test this code". The answer is pretty much opinion based so I'm voting to close it as such.
– Esko
Nov 9 at 11:01
Are there rules/suggestions around which parts of the code are suitable for testing and which type, ie unit,integration, system?
– CerIs
Nov 9 at 11:02
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
In its present state I dont think I can test it because of the dependencies on user authentication (user.identity) and route data (RouteData.Values), original plan was to check if it was returning a view. Should I try to mock/fake these values or not be testing a controller like this in first place?
public IActionResult Index()
BlogHomeVM vm = new BlogHomeVM();
int skip = int.TryParse((string)this.RouteData.Values["skip"], out skip) ? skip : 0;
int showPosts = 3;
vm.PageTitle = "Async and wait";
vm.totalPosts = _context.Posts.Where(y => y.PublishedFrom <= DateTime.Now).Count();
vm.Posts = _context.Posts
.Where(y => y.PublishedFrom <= DateTime.Now .net unit-testing
asked Nov 9 at 10:58
CerIs
13418
In its present state I dont think I can test it because of the dependencies on user authentication (user.identity) and route data (RouteData.Values), original plan was to check if it was returning a view. Should I try to mock/fake these values or not be testing a controller like this in first place?
public IActionResult Index()
BlogHomeVM vm = new BlogHomeVM();
int skip = int.TryParse((string)this.RouteData.Values["skip"], out skip) ? skip : 0;
int showPosts = 3;
vm.PageTitle = "Async and wait";
vm.totalPosts = _context.Posts.Where(y => y.PublishedFrom <= DateTime.Now).Count();
vm.Posts = _context.Posts
.Where(y => y.PublishedFrom <= DateTime.Now public IActionResult Index()
BlogHomeVM vm = new BlogHomeVM();
int skip = int.TryParse((string)this.RouteData.Values["skip"], out skip) ? skip : 0;
int showPosts = 3;
vm.PageTitle = "Async and wait";
vm.totalPosts = _context.Posts.Where(y => y.PublishedFrom <= DateTime.Now).Count();
vm.Posts = _context.Posts
.Where(y => y.PublishedFrom <= DateTime.Now public IActionResult Index()
BlogHomeVM vm = new BlogHomeVM();
int skip = int.TryParse((string)this.RouteData.Values["skip"], out skip) ? skip : 0;
int showPosts = 3;
vm.PageTitle = "Async and wait";
vm.totalPosts = _context.Posts.Where(y => y.PublishedFrom <= DateTime.Now).Count();
vm.Posts = _context.Posts
.Where(y => y.PublishedFrom <= DateTime.Now .net unit-testing
.net unit-testing
asked Nov 9 at 10:58
CerIs
13418
asked Nov 9 at 10:58
CerIs
13418
asked Nov 9 at 10:58
CerIs
13418
asked Nov 9 at 10:58
CerIs
13418
asked Nov 9 at 10:58
CerIs
13418
13418
1
You question is basically "should I test this code". The answer is pretty much opinion based so I'm voting to close it as such.
– Esko
Nov 9 at 11:01
Are there rules/suggestions around which parts of the code are suitable for testing and which type, ie unit,integration, system?
– CerIs
Nov 9 at 11:02
add a comment |
1
You question is basically "should I test this code". The answer is pretty much opinion based so I'm voting to close it as such.
– Esko
Nov 9 at 11:01
Are there rules/suggestions around which parts of the code are suitable for testing and which type, ie unit,integration, system?
– CerIs
Nov 9 at 11:02
1
1
You question is basically "should I test this code". The answer is pretty much opinion based so I'm voting to close it as such.
– Esko
Nov 9 at 11:01
You question is basically "should I test this code". The answer is pretty much opinion based so I'm voting to close it as such.
– Esko
Nov 9 at 11:01
Are there rules/suggestions around which parts of the code are suitable for testing and which type, ie unit,integration, system?
– CerIs
Nov 9 at 11:02
Are there rules/suggestions around which parts of the code are suitable for testing and which type, ie unit,integration, system?
– CerIs
Nov 9 at 11:02
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
You can inject IHttpContextAccessor into your controller and use _httpContext.GetRouteData() and _httpContext.User to make it testable.
Read this article to understand what to test and how to write testable code - https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
Seems little bid odd injectingIHttpContextAccessor, because controller already have access to the currentHttpContext
– Fabio
Nov 9 at 23:05
@Fabio not odd at all, you inject it so you can mock it later. You cannot mockHttpContextproperty.
– Sergey Kolodiy
Nov 12 at 17:22
I don't need to mockHttpContext, instead I can create it and inject to the controller. Possible I will need to mockIIdentityto provide expected value forIsAuthenticated.
– Fabio
Nov 14 at 18:26
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
You can inject IHttpContextAccessor into your controller and use _httpContext.GetRouteData() and _httpContext.User to make it testable.
Read this article to understand what to test and how to write testable code - https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
Seems little bid odd injectingIHttpContextAccessor, because controller already have access to the currentHttpContext
– Fabio
Nov 9 at 23:05
@Fabio not odd at all, you inject it so you can mock it later. You cannot mockHttpContextproperty.
– Sergey Kolodiy
Nov 12 at 17:22
I don't need to mockHttpContext, instead I can create it and inject to the controller. Possible I will need to mockIIdentityto provide expected value forIsAuthenticated.
– Fabio
Nov 14 at 18:26
add a comment |
up vote
1
down vote
accepted
You can inject IHttpContextAccessor into your controller and use _httpContext.GetRouteData() and _httpContext.User to make it testable.
Read this article to understand what to test and how to write testable code - https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
Seems little bid odd injectingIHttpContextAccessor, because controller already have access to the currentHttpContext
– Fabio
Nov 9 at 23:05
@Fabio not odd at all, you inject it so you can mock it later. You cannot mockHttpContextproperty.
– Sergey Kolodiy
Nov 12 at 17:22
I don't need to mockHttpContext, instead I can create it and inject to the controller. Possible I will need to mockIIdentityto provide expected value forIsAuthenticated.
– Fabio
Nov 14 at 18:26
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
You can inject IHttpContextAccessor into your controller and use _httpContext.GetRouteData() and _httpContext.User to make it testable.
Read this article to understand what to test and how to write testable code - https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
You can inject IHttpContextAccessor into your controller and use _httpContext.GetRouteData() and _httpContext.User to make it testable.
Read this article to understand what to test and how to write testable code - https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
answered Nov 9 at 11:05
Sergey Kolodiy
4,29812345
4,29812345
Seems little bid odd injectingIHttpContextAccessor, because controller already have access to the currentHttpContext
– Fabio
Nov 9 at 23:05
@Fabio not odd at all, you inject it so you can mock it later. You cannot mockHttpContextproperty.
– Sergey Kolodiy
Nov 12 at 17:22
I don't need to mockHttpContext, instead I can create it and inject to the controller. Possible I will need to mockIIdentityto provide expected value forIsAuthenticated.
– Fabio
Nov 14 at 18:26
add a comment |
Seems little bid odd injectingIHttpContextAccessor, because controller already have access to the currentHttpContext
– Fabio
Nov 9 at 23:05
@Fabio not odd at all, you inject it so you can mock it later. You cannot mockHttpContextproperty.
– Sergey Kolodiy
Nov 12 at 17:22
I don't need to mockHttpContext, instead I can create it and inject to the controller. Possible I will need to mockIIdentityto provide expected value forIsAuthenticated.
– Fabio
Nov 14 at 18:26
Seems little bid odd injecting
IHttpContextAccessor, because controller already have access to the current HttpContext– Fabio
Nov 9 at 23:05
Seems little bid odd injecting
IHttpContextAccessor, because controller already have access to the current HttpContext– Fabio
Nov 9 at 23:05
@Fabio not odd at all, you inject it so you can mock it later. You cannot mock
HttpContext property.– Sergey Kolodiy
Nov 12 at 17:22
@Fabio not odd at all, you inject it so you can mock it later. You cannot mock
HttpContext property.– Sergey Kolodiy
Nov 12 at 17:22
I don't need to mock
HttpContext, instead I can create it and inject to the controller. Possible I will need to mock IIdentity to provide expected value for IsAuthenticated.– Fabio
Nov 14 at 18:26
I don't need to mock
HttpContext, instead I can create it and inject to the controller. Possible I will need to mock IIdentity to provide expected value for IsAuthenticated.– Fabio
Nov 14 at 18:26
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53224410%2fis-this-controller-untestable%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
You question is basically "should I test this code". The answer is pretty much opinion based so I'm voting to close it as such.
– Esko
Nov 9 at 11:01
Are there rules/suggestions around which parts of the code are suitable for testing and which type, ie unit,integration, system?
– CerIs
Nov 9 at 11:02