Board index » Visual Studio » Bypassing Test Code

Visual Studio217
Here's a rookie question.



How do you pros bypass test code when not needed for awhile, but you don't

want to delete it until you are absolutely certain you won't need it later?



Do you comment all the line with the single quote?



Do you plant a bunch of...



Goto SKIPTEST

...

test code

...

SKIPTEST:



...within your code?



Or is there better ways to do this?



Also, I often find I need to stop the code at some value or date to then

step through a routine. This is what I do alot of...



If dMyDate = "01/23/1995" then

x = x

end if



And then highlight x = x with a breakpoint. Naturally x=x does nothing.



I can't help thinking there are smarter ways to do all this.



Anyone?



Thanks.



Webbiz

(trying to break out of old weak trading habits)


-

"Webbiz" <noreply@cox.net>schrieb im Newsbeitrag

I use a compiler constant:



#If USED then

Unused code...

#End If



You can do this with the same constant all over the project. You do not even

have to declare the constant anywhere (#Const USED = 0) because it is

initialized to 0 so this is very easy to handle. To check/clean all my

unused code I simply search for "#If USED then" once in a while.



Don



-

"Webbiz" <noreply@cox.net>wrote in message

Often. The button that comments out a selected block makes it pretty easy. I do

delete them pretty agressively, otherwise they accumulate pretty quickly.





I sometimes use

If True Then

' test code

End If



And then change True to False to bypass it. Goto is too wierd.





What's up with the date compared to a string?



You can use

Debug.Assert dMyDate <>"01/23/1995"



which will break (with a beep) if the expression is false.



Also you can do conditional watches. If you make a watch expression

dMyDate = "01/23/1995"

you can check the box "Break when Value is True". It will break on the next

line.







-

On Thu, 5 Jul 2007 23:18:20 -0600, "Webbiz" <noreply@cox.net>wrote:

in <ey9h8S4vHHA.1524@TK2MSFTNGP06.phx.gbl>



Whenever I'm making changes for a new version I always copy and paste

the original section of code, comment it using the comment block

command, and then edit the copy for changes. That way, it's a simple

matter of using the Uncomment Block command to revert.



---

Stefan Berglund

-

Webbiz wrote:

Several posters recommended the block comment and block un-comment

method. You can add the icons for those commands to your toolbar by:



View, Toolbars, Customize and clicking the Commands tab.



Under Edit, scroll down to the Comment Block and drag the icon up to the

toolbar where you want it to appear. Do the same with the UnComment

Block icon.



Now you can highlight multiple lines in the editor and hit the

appropriate toolbar icon to handle the block.



--

'--------------------------

' John Mishefske

' UtterAccess Editor

' 2007 Microsoft Access MVP

'--------------------------

-

Stefan Berglund <sorry.no.koolaid@for.me>'s wild thoughts

were released on Thu, 05 Jul 2007 23:29:04 -0700 bearing the

following fruit:



Same here along with who made the change, when it was made

and why.





--

Jan Hyde



https://mvp.support.microsoft.com/profile/Jan.Hyde

-

John Mishefske <jmishefskeNO@SPAMyahoo.com>'s wild thoughts

were released on Fri, 06 Jul 2007 01:48:46 -0500 bearing the

following fruit:



And better still map them to the keyboard (MZTools makes

this easy)



I use Crtl+q and ctrl+w to comment\uncomment. Nothing worse

than having to reach for the mouse when your typing.

--

Jan Hyde



https://mvp.support.microsoft.com/profile/Jan.Hyde

-

"Webbiz" <noreply@cox.net>wrote



What type of 'test code' are you talking about?



To see the values of a few variables:



Debug.Print X, Y, DX, DY



(Put a breakpoint on that line and test up to that point. Comment it out

when not needed)



To fill a list with simple test data:



Debug.Print "For x = 1 to 100: List(x) = x: Next";



(Put a breakpoint on that line and test up to that point, then after entering

debug mode, execute that line and go to the Immediate window to press Enter

which will run the loop and fill the list. Commenting out that one line avoids

filling the list with test data.)



For more complicated scenareos, add a Test module with functions

to do the tests and call them in your code:



Debug.Assert FooBar()



If you want to stop at that point, make FooBar return False, otherwise

make FooBar return True. Comment it out when not needed.



(When finished with the project, remove the Test module. Any active

assertions left in your code will abort compilation. Meaning, you can't forget

to take them all out because with the Test module removed, the project won't

compile if any of the assertions are left active (uncommented).



Also use Assert to break on conditional statements:



Debug.Assert dMyDate <>#01/23/1995#



(Stops when condition is False; eg: when dMyDate = 01/23/1995)



HTH

LFS





-

"Henning" <computer_hero@coldmail.com>skrev i meddelandet



#If Testing then



testcode



#End If



Now if Testing is False, it will not even compile the testcode.



/Henning





-

"Webbiz" <noreply@cox.net>skrev i meddelandet

know, but I still love them :)

Public Const Testing = True 'or False





If Testing Then



testcode

Else



maybe needed



End If



/Henning





-

"Webbiz" <noreply@cox.net>wrote in message

I'm in the "Conditional Compilation" crowd. I use it all the time... even

for important comments.



Private Sub Command1_Click()

#If DESIGN_NOTE Then

//This is red, so it sticks out like a sore thumb

#End If

End Sub





--

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..

In Loving Memory - www.vbsight.com/Remembrance.htm">www.vbsight.com/Remembrance.htm





-

Henning <computer_hero@coldmail.com>wrote:

I often do similarly, but I set the flag value to True using an optional command

line parameter. This allows me to see things that only happen inside the EXE and/or

only on certain machines, etc.

--

.NET: It's About Trust!

vfred.mvps.org">vfred.mvps.org





-

There was a lot of response to my question, so I thought I'd say THANKS to

everyone that chipped in.



The Block/Unblock appears to be what I need. Didn't even know it existed.

Also, the MZTools tip was great also, so I installed that and setup my

shortcuts. Great!



I'm not sure the question on the conditional code was answered though, or

prehaps not understood.



For example:



Suppose that I have some code that runs through a lot of stock prices and

plots it on a price chart. Looking at the chart, I notice that there seems

to be a problem at 1/12/1990 on the chart.



So in my code, with perhaps 4000 days of data running through it, I don't

want to step through it a hundred or thousand times.



So if the date is stored in variable MyData.DateStamp, I use something like

this...



'TEST CODE



If MyData.DateStamp = "01/12/1990" then

x = x

end if



Then I place the breakpoint on x=x.



I put x=x so that nothing is changed in the code (especially to x).



Me thinks this isn't the best way to do this. Maybe it is. I wanted to find

out from the more experienced in this group.



Any comments?



(Again, a BIG thanks for all your help and contributions.)



Webbiz









"John Mishefske" <jmishefskeNO@SPAMyahoo.com>wrote in message



-

"Webbiz" <noreply@cox.net>wrote



Replace with:



Debug.Assert MyData.DateStamp <>#01/12/1990#





When that date rolls around, the condition will be false causing the

Assert routine to enter into break mode.



LFS







-

Very low tech but it works for me:



I keep the comment/inset toolbar in view, so that I

can comment or uncomment selected blocks

easily. Then anything that's in process gets a unique

string. I use: '--temp



That way I can do a quick search for '--temp to adjust

comments before running in the IDE. I also find it

handy for compile-time. A quick search for '--temp

then lets me take care of any compile-specific changes

I might need to make, like, for instance, commented code

that checks for a license and needs to be uncommented

before shipping.





-

"Larry Serflaten" <serflaten@usinternet.com>wrote in message

That, or use a conditional watch expression.



Click Debug, Add Watch.

Make the Expression

MyData.DateStamp = #1/12/1990#

Check the box "Break When Value Is True"



You can also specify the context, or scope, of the watch.







-

"Webbiz" <noreply@cox.net>'s wild thoughts were released on

Sun, 8 Jul 2007 02:20:10 -0600 bearing the following fruit:



I sometimes have trouble with breakpoints, and sometimes use

a Stop statement where you currently have x=x



But this has a drawback in that it will be compiled if you

don't remember to remove it.





--

Jan Hyde



https://mvp.support.microsoft.com/profile/Jan.Hyde

-

Thanks for your comments Steve.



I added the variable to the Watch, but where is this 'box' you speak of?



I don't see any box to check "Break When Value is True" or anything else.

Where is this box located? It's not in my Watch window.



??



Thx.

Webbiz



"Steve Gerrard" <mynamehere@comcast.net>wrote in message



-

Sweet. Thanks Larry.





"Larry Serflaten" <serflaten@usinternet.com>wrote in message



-

"Webbiz" <noreply@cox.net>wrote in message

In the watch window, right click on one of the watches you have set up and

select 'Edit Watch'. You should see a dialog with a frame near the bottom

left that reads "Watch Type". There are 3 choices there... the following

text is what you see when you click the Help button on that dialog.



Watch Type:



Determines how Visual Basic responds to the watch expression.



Watch Expression ? Displays the watch expression and its value in the Watch

window. When you enter break mode, the value of the watch expression is

automatically updated.



Break When Value Is True ? Execution automatically enters break mode when

the expression evaluates to true or is any nonzero value (not valid for

string expressions).



Break When Value Changes ? Execution automatically enters break mode when

the value of expression changes within the specified context.



--

Ken Halter - MS-MVP-VB - Please keep all discussions in the groups..

In Loving Memory - www.vbsight.com/Remembrance.htm">www.vbsight.com/Remembrance.htm





-

Okay. Found it.



Thanks Ken.



:-)

Webbiz





"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com>wrote in message



-