Unit Testing for VS2017 project
I have an ASP.NET application (a basic form where I capture some input) in VS2017.
One of the fields on the form is Mark, which is an integer.
I have the following block of code for the Mark, in my .cs file.
[Display(Name = "Mark")]
[Range(1, 10, ErrorMessage = "Mark must be between 1 and 10")]
public int Mark get; set;
I've created a MSTest project for this application to write Unit Tests.
My question is, do you write Test Cases for this block to verify the input value is in the expected range?
If yes, how you write that?
I've started with this.
[DataRow(0, "Mark must be between 1 and 10")]
[DataRow(11, "Mark must be between 1 and 10")]
[DataTestMethod]
public void TestMark_IsMarkValid_NotValid(int mark, string expectedMsg)
//Arrange
Student testStudent = new Student();
testStudent.Mark = mark; //this does not throw any error, although the assigned value is outside of the defined range. But it looks like the range validation only applies to the webform.
//Act
string actualMsg = "Mark must be between 1 and 10"; //this is not correct. I was thinking to capture in the actual result the error message yield by the Range validation, but assigning a value outside range doesn't yield any error message.
//Assert
Assert.AreEqual(expectedMsg, actualMsg);
Now, not sure if that block should be in scope for unit testing. If it should be, I have a feeling the approach I've taken is not correct.
Any thoughts, please?
Many thanks,
Cosmin
c# visual-studio unit-testing visual-studio-2017 mstest
add a comment |
I have an ASP.NET application (a basic form where I capture some input) in VS2017.
One of the fields on the form is Mark, which is an integer.
I have the following block of code for the Mark, in my .cs file.
[Display(Name = "Mark")]
[Range(1, 10, ErrorMessage = "Mark must be between 1 and 10")]
public int Mark get; set;
I've created a MSTest project for this application to write Unit Tests.
My question is, do you write Test Cases for this block to verify the input value is in the expected range?
If yes, how you write that?
I've started with this.
[DataRow(0, "Mark must be between 1 and 10")]
[DataRow(11, "Mark must be between 1 and 10")]
[DataTestMethod]
public void TestMark_IsMarkValid_NotValid(int mark, string expectedMsg)
//Arrange
Student testStudent = new Student();
testStudent.Mark = mark; //this does not throw any error, although the assigned value is outside of the defined range. But it looks like the range validation only applies to the webform.
//Act
string actualMsg = "Mark must be between 1 and 10"; //this is not correct. I was thinking to capture in the actual result the error message yield by the Range validation, but assigning a value outside range doesn't yield any error message.
//Assert
Assert.AreEqual(expectedMsg, actualMsg);
Now, not sure if that block should be in scope for unit testing. If it should be, I have a feeling the approach I've taken is not correct.
Any thoughts, please?
Many thanks,
Cosmin
c# visual-studio unit-testing visual-studio-2017 mstest
add a comment |
I have an ASP.NET application (a basic form where I capture some input) in VS2017.
One of the fields on the form is Mark, which is an integer.
I have the following block of code for the Mark, in my .cs file.
[Display(Name = "Mark")]
[Range(1, 10, ErrorMessage = "Mark must be between 1 and 10")]
public int Mark get; set;
I've created a MSTest project for this application to write Unit Tests.
My question is, do you write Test Cases for this block to verify the input value is in the expected range?
If yes, how you write that?
I've started with this.
[DataRow(0, "Mark must be between 1 and 10")]
[DataRow(11, "Mark must be between 1 and 10")]
[DataTestMethod]
public void TestMark_IsMarkValid_NotValid(int mark, string expectedMsg)
//Arrange
Student testStudent = new Student();
testStudent.Mark = mark; //this does not throw any error, although the assigned value is outside of the defined range. But it looks like the range validation only applies to the webform.
//Act
string actualMsg = "Mark must be between 1 and 10"; //this is not correct. I was thinking to capture in the actual result the error message yield by the Range validation, but assigning a value outside range doesn't yield any error message.
//Assert
Assert.AreEqual(expectedMsg, actualMsg);
Now, not sure if that block should be in scope for unit testing. If it should be, I have a feeling the approach I've taken is not correct.
Any thoughts, please?
Many thanks,
Cosmin
c# visual-studio unit-testing visual-studio-2017 mstest
I have an ASP.NET application (a basic form where I capture some input) in VS2017.
One of the fields on the form is Mark, which is an integer.
I have the following block of code for the Mark, in my .cs file.
[Display(Name = "Mark")]
[Range(1, 10, ErrorMessage = "Mark must be between 1 and 10")]
public int Mark get; set;
I've created a MSTest project for this application to write Unit Tests.
My question is, do you write Test Cases for this block to verify the input value is in the expected range?
If yes, how you write that?
I've started with this.
[DataRow(0, "Mark must be between 1 and 10")]
[DataRow(11, "Mark must be between 1 and 10")]
[DataTestMethod]
public void TestMark_IsMarkValid_NotValid(int mark, string expectedMsg)
//Arrange
Student testStudent = new Student();
testStudent.Mark = mark; //this does not throw any error, although the assigned value is outside of the defined range. But it looks like the range validation only applies to the webform.
//Act
string actualMsg = "Mark must be between 1 and 10"; //this is not correct. I was thinking to capture in the actual result the error message yield by the Range validation, but assigning a value outside range doesn't yield any error message.
//Assert
Assert.AreEqual(expectedMsg, actualMsg);
Now, not sure if that block should be in scope for unit testing. If it should be, I have a feeling the approach I've taken is not correct.
Any thoughts, please?
Many thanks,
Cosmin
c# visual-studio unit-testing visual-studio-2017 mstest
c# visual-studio unit-testing visual-studio-2017 mstest
edited Nov 15 '18 at 2:28
Jayendran
3,20631336
3,20631336
asked Nov 12 '18 at 9:18
CosminCosmin
274
274
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Interesting question. I'm not certain that there is a definitively correct answer. But here are my thoughts :
1) "Mark" is a property. We don't need to unit test a property because Microsoft have already tested that properties work.
2) The attributes do not affect the property, but provide information about the property that others can use. That is why your unit test passes the test for the value. The form uses the attributes, your unit test does not. That is why your unit test can assign any value.
3) If you really want to limit the value of the variable then limit it in the Student class - either by a setter or else explicit get/set and a backing variable - you can never trust any data submitted by the browser.
4) Testing a UI is not easy. We have a test team that tests by hand. We have tried several tools but none is outstanding. Keep your business logic out of your UI and put it in business classes where it can be easily tested.
So, to answer your question, I personally would not test that the attribute functions in a unit test.
I hope that helps.
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
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%2f53259041%2funit-testing-for-vs2017-project%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Interesting question. I'm not certain that there is a definitively correct answer. But here are my thoughts :
1) "Mark" is a property. We don't need to unit test a property because Microsoft have already tested that properties work.
2) The attributes do not affect the property, but provide information about the property that others can use. That is why your unit test passes the test for the value. The form uses the attributes, your unit test does not. That is why your unit test can assign any value.
3) If you really want to limit the value of the variable then limit it in the Student class - either by a setter or else explicit get/set and a backing variable - you can never trust any data submitted by the browser.
4) Testing a UI is not easy. We have a test team that tests by hand. We have tried several tools but none is outstanding. Keep your business logic out of your UI and put it in business classes where it can be easily tested.
So, to answer your question, I personally would not test that the attribute functions in a unit test.
I hope that helps.
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
add a comment |
Interesting question. I'm not certain that there is a definitively correct answer. But here are my thoughts :
1) "Mark" is a property. We don't need to unit test a property because Microsoft have already tested that properties work.
2) The attributes do not affect the property, but provide information about the property that others can use. That is why your unit test passes the test for the value. The form uses the attributes, your unit test does not. That is why your unit test can assign any value.
3) If you really want to limit the value of the variable then limit it in the Student class - either by a setter or else explicit get/set and a backing variable - you can never trust any data submitted by the browser.
4) Testing a UI is not easy. We have a test team that tests by hand. We have tried several tools but none is outstanding. Keep your business logic out of your UI and put it in business classes where it can be easily tested.
So, to answer your question, I personally would not test that the attribute functions in a unit test.
I hope that helps.
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
add a comment |
Interesting question. I'm not certain that there is a definitively correct answer. But here are my thoughts :
1) "Mark" is a property. We don't need to unit test a property because Microsoft have already tested that properties work.
2) The attributes do not affect the property, but provide information about the property that others can use. That is why your unit test passes the test for the value. The form uses the attributes, your unit test does not. That is why your unit test can assign any value.
3) If you really want to limit the value of the variable then limit it in the Student class - either by a setter or else explicit get/set and a backing variable - you can never trust any data submitted by the browser.
4) Testing a UI is not easy. We have a test team that tests by hand. We have tried several tools but none is outstanding. Keep your business logic out of your UI and put it in business classes where it can be easily tested.
So, to answer your question, I personally would not test that the attribute functions in a unit test.
I hope that helps.
Interesting question. I'm not certain that there is a definitively correct answer. But here are my thoughts :
1) "Mark" is a property. We don't need to unit test a property because Microsoft have already tested that properties work.
2) The attributes do not affect the property, but provide information about the property that others can use. That is why your unit test passes the test for the value. The form uses the attributes, your unit test does not. That is why your unit test can assign any value.
3) If you really want to limit the value of the variable then limit it in the Student class - either by a setter or else explicit get/set and a backing variable - you can never trust any data submitted by the browser.
4) Testing a UI is not easy. We have a test team that tests by hand. We have tried several tools but none is outstanding. Keep your business logic out of your UI and put it in business classes where it can be easily tested.
So, to answer your question, I personally would not test that the attribute functions in a unit test.
I hope that helps.
answered Nov 12 '18 at 10:03
MarkMark
21149
21149
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
add a comment |
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
Very well made points. I agree the UI and the business logic should be kept separate. Thanks for your input.
– Cosmin
Nov 12 '18 at 11:33
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.
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%2f53259041%2funit-testing-for-vs2017-project%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