| || |
Re: explicit option on
Well, Visual Basic 6.0 and prior has just "Option Explicit" while VB.NET has "Option Explicit" and "Option Strict." But, either way, the point is to help with variables that are not declared to be declared as something. I think in VB.NET, the "Option Explicit" is now always on, but "Option Strict" can be turned on and off.
In any event, however, some negative testing is offset by the use of Option Explicit. In other words, the point is to help you not make mistakes in your code by using those parameters. When those mistakes do not occur in the code, they do not (indeed cannot) appear in the final product - at least in that strict form.
In other words, if the code itself prevents you from doing something then the code is serving as its own negative test. (To a certain degree! You have to be careful about how you rely on this idea.) Also remember that "Option Explicit" only specified that variables were declared. You could still (I think) have some datatype errors but "Option Strict" is new to VB.NET and prevents that from occurring.
Arrrghh. I am not explaining this well. Consider it this way:
The "Option Strict" setting in VB.NET and is used to require that any conversion from one data type to another in which data may be lost be done explicitly by the developer. This prevents (or helps prevent) runtime defects as it ensures that the programmer is fully aware that a conversion is happening and is reminded to perform any necessary validity checking or add appropriate error trapping at that time.
That is when your negative testing (negative unit testing, in this case) occurs.
Does anything I just said make sense?
Re: explicit option on
Thanks JeffNyman, i got your email too.
I guess my issue is, right now we have VB.Net and both options (explicit & strict) are on, and most of our test data are: GUID, date, string, and integers.
I can come up with some scenarios to test the integers.
and i can (maybe) come with some scenario to get the date & string.
But i really can't come up with any negative scenario to test the GUID.
with these two options ON, we really can't do alot of negative testing.
Another quetsion about the negative testing, if we have a field that should accept only numeric values and if we enter a char. the system displays an error message.
then if we test it by entering a char, and the system displayed an error message, is that a sanity test or negative test?
Re: explicit option on
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by qa_tester:
But i really can't come up with any negative scenario to test the GUID.<HR></BLOCKQUOTE>
Well, all a GUID is a type of identifier and it should never be a duplicate. So one thing you could do might be:
Create a form that has a CommandButton (call it cmdGUID) and a TextBox (call it txtGUID). Now put the following code in the form:
Run the project and press the command button that you added to the form and you will see a GUID appear in the text field. This can show you the GUID that is being created. This is a little bit old-school, however, because in VB.NET you could just use:
I guess, however, it depends on what you are testing with the GUID, since it is just an algorithmically derived reference number.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>with these two options ON, we really can't do alot of negative testing.<HR></BLOCKQUOTE>
Well, in a way you can - it is just done implicitly when you are coding the application. That is what I meant in my previous post. The explicit options force the programmer to follow the rules so that runtime errors do not occur.
Consider the following without any explicit options:
Text1.Text = Text1.Text + 1
Visual Basic will attempt to convert the string stored in the Text property of the TextBox control (Text1) to an integer, add 1, and then convert the result back to string format. If the TextBox does not contain a valid numeric value then a runtime error will occur. In VB.NET, with "Option Strict" on, the compiler would flag such a statement as an error and require that it be rewritten like this:
Text1.Text = CStr(CInt(Text1.Text) + 1)
Text1.Text = (Convert.ToInt32(Text1.Text) + 1).ToString
(You should note that "widening" conversions are allowed in VB.NET.)
Also remember that with "Option Strict" on all objects must be early-bound. Late-bound references cannot be resolved until runtime. If you want to get around this, you would have to create modules with "Option Strict" in the off state. Then the classes in that module can expose known data types to the rest of the project.
<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Another quetsion about the negative testing, if we have a field that should accept only numeric values and if we enter a char. the system displays an error message. then if we test it by entering a char, and the system displayed an error message, is that a sanity test or negative test?<HR></BLOCKQUOTE>
You could consider it negative testing or, perhaps more appropriately, boundary testing. You are testing the boundaries of the input parameters. In this case, your boundary is only numeric characters. Thus a non-number violates the boundary and thus should generate an error. The same would apply to any character that is not numeric. So typing in a !, #, or $ symbol should show a similar boundary violation and thus error-handling code should be executed.
explicit option on
Have any one done unit testing on VB when the explicit option is ON?
the issue is: if this option is on, it means we can't pass a different data type, hence, we can't test any negative testing!
the problem is i can't make my developers test any negative testing in their unit testing because this option is on, how did u solve this problem?