Code center > Solved Bugs
Yet another overflow bug from Testlund
Numsgil:
--- Quote from: Botsareus on January 14, 2014, 12:23:36 PM ---I don't know the .NET package or optional components well enough to answer the question(s) actually. I would love to read Numsgil's take on this.
--- End quote ---
In regards to what specifically?
In terms of unit tests, there's some stuff built in to Visual Studio, but it's not available in the free Express version, so I've been avoiding them and instead using my own unit testing framework.
In terms of performance, I usually use slimtune for .NET projects. It's not full featured at all, but it's the best for what I need to do (identifying hot spots).
--- Quote from: Botsareus on January 14, 2014, 03:21:48 PM ---Dude, I do not leave them as comments in the code.
By unit tests I mean I usually visually confirm that what I put in is happening:
Most of the time I just break the execution and/or throw break points and see what kind of values I am dealing with.
--- End quote ---
"Unit testing" has a very specific meaning in software development. See this article series, for instance.
That isn't unit testing. I don't think there's a name for that style, but it's what coders traditionally did in the past. It's falling out of vogue (a few vocal holdouts notwithstanding) in favor of constant automated testing. Basically proving the code works right now by showing that its output matches a predetermined known good value.
Botsareus:
Thank you for clearing it up Numsgil. :)
edit:
--- Quote ---Let?s take a moment to think about how you write code without using test-driven development. You decide you need to implement some piece of functionality, you mentally break the problem into smaller problems, and you start working on each of them. While you write code, your only guide for whether you?re heading in the right direction or not is whether your code continues to compile. Once you?ve assembled a minimum number of those smaller subtasks, your program might even be able to run. So you fire up the game or tool and ?see? if it works. If it?s not obvious (or if it doesn?t work at all), maybe you break in the debugger and try to step into the code you just wrote to make sure the program is doing what you intended. Once you see it do its thing, you happily commit it to version control and move on to some other task.
--- End quote ---
lol, that is exactly what I do.
Peter:
--- Quote from: Numsgil on January 14, 2014, 04:25:13 PM ---
--- Quote from: Botsareus on January 14, 2014, 12:23:36 PM ---I don't know the .NET package or optional components well enough to answer the question(s) actually. I would love to read Numsgil's take on this.
--- End quote ---
In regards to what specifically?
--- End quote ---
Something like smoke testing if functions are resistant against junk as input. Although that's likely not useful for DB2. Much odds for false positives and junk may turn into destructive junk for other functions but not crash.
TTD useful to do, because it forces you to write code in a way that suits testing. Preaching this, yet I can't say that I've used the order of unit-test->code consistently... :P
If you implement unit testing(sure it exists, but clueless on how it works in VB6) it's handy to write down future bugs as unit tests(that fail). So when you fix it you got a unit test that'll make sure similar errors will be seen.
Botsareus:
It is just hard for me to write tests using code. Usually my brain is the test. Otherwise it seems like a waste of time for me, example:
a + b = c
Do I really have to test?
--- Code: ---if a = 2 and b = 3 and c = 5 then msgbox "pass"
--- End code ---
Reading article further...
Botsareus:
Also, how am I supposed to write a test that is designed to fail? There is only one way that
--- Code: ---a + b = c
--- End code ---
and infinite ways
--- Code: ---a + b <> c
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version