Unit testing
-
Well... I think you're missing the fact that the little unit tests you write after you write you're gone gets done on a much greater scale than you think. Banking software, life critical software (medical systems, and military/commercial aircraft systems), ect. companies employ whole teams of unit testers to ensure some level of standard. Unit testing is only one type of testing that gets performed on these software systems in order to minimize failure. Yes unit testing your own stuff is good, however the real power of unit testing comes in where someone else tests your stuff, as one tends to not see your own mistakes. The topic of proper unit testing is a completely different one. Proper unit testing can only be done if the necessary things was done before hand in order for you to write your unit tests. You should have some form of a design document (preferable not generated from code) which enables you to right your tests. You should never write your tests from the actual source. (However can also find one or two bugs this way). Testing = Quality = Happy Customer = $$$ in an perfect world that is. Testing = Good marketing pitch
"Program testing can be used to show the presence of bugs, but never to show their absence." << please vote!! >>
R. Erasmus wrote:
Testing = Good marketing pitch
It should be: Testing = Good marketing pitch = Happy Customer (Until it buys the product) = $$$ :laugh:
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Slacker007 wrote:
Unit testing should be done by someone else, IMHO
Now, there's a [new to me] good idea. Glad I asked.
IMO, even if you do have someone else unit-testing your code it's a good idea to write your own unit tests. I've always built a generic utility program that I use for that and just add onto it every time I write a significant routine. It's actually kind of fun and has resulted in handy utilities that I wound up using later! I've never used any of the "formal" unit testing stuff that are supposedly "best practice" nowadays, I've just always been in the habit of writing programs that test the boundaries of code I write. Guess I've been at this too long. -CB :-)
-
Gary Huck wrote:
Is such a thing not part of every programmer's everyday life? Are not unit tests just something that is done for every little module one writes?
Nope. There's probably lots of software out there that isn't even tested at all...
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Naerling wrote:
Nope. There's probably lots of software out there that isn't even tested at all...
You got that right. I have had to clean up more than my share of messes after people who threw code together and never ran it. I'm serious: I've seen code in our system that was obvious to me that no one put it to any kind of test *at all* as it could crash the system as soon as it was exercised. I've even seen an occasional section checked in where it was obviously not even compiled before being checked-in! :wtf: If you're writing a new code section or fixing a bug, at least run the code before turning it in, huh? I hate to say it, folks: but sometimes our work can be hard. It takes WORK. (Oops, there's that 4-letter word again!) Some people just don't need to be doing this. -CB
-
Naerling wrote:
Nope. There's probably lots of software out there that isn't even tested at all...
You got that right. I have had to clean up more than my share of messes after people who threw code together and never ran it. I'm serious: I've seen code in our system that was obvious to me that no one put it to any kind of test *at all* as it could crash the system as soon as it was exercised. I've even seen an occasional section checked in where it was obviously not even compiled before being checked-in! :wtf: If you're writing a new code section or fixing a bug, at least run the code before turning it in, huh? I hate to say it, folks: but sometimes our work can be hard. It takes WORK. (Oops, there's that 4-letter word again!) Some people just don't need to be doing this. -CB
CodeBubba wrote:
people who threw code together and never ran it
Yep, I know it. I've worked with someone who checked in some code after weeks of work. It was all set and ready to be delivered to the customer. So I thought I'd see what she made and the first button I pressed crashed the software. I assumed this was a minor bug that she had missed, but as I restarted it became appearent this wasn't a single bug. Crash after crash after crash... Here's the deal, the programmer had one test case which worked fine, but she never tested anything else. I removed her test data before testing and all hell broke loose. As I had promised our customer that we would deliver that same week I made a 30+ hour weekend just to be able to deliver on monday... :sigh:
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
CodeBubba wrote:
people who threw code together and never ran it
Yep, I know it. I've worked with someone who checked in some code after weeks of work. It was all set and ready to be delivered to the customer. So I thought I'd see what she made and the first button I pressed crashed the software. I assumed this was a minor bug that she had missed, but as I restarted it became appearent this wasn't a single bug. Crash after crash after crash... Here's the deal, the programmer had one test case which worked fine, but she never tested anything else. I removed her test data before testing and all hell broke loose. As I had promised our customer that we would deliver that same week I made a 30+ hour weekend just to be able to deliver on monday... :sigh:
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}Naerling wrote:
Here's the deal, the programmer had one test case which worked fine, but she never tested anything else. I removed her test data before testing and all hell broke loose. As I had promised our customer that we would deliver that same week I made a 30+ hour weekend just to be able to deliver on monday... :sigh:
It's frightening to think about how much software there might be out there that is just "one scenario" away from blowing away a database, isn't it? :omg:
-
Naerling wrote:
Here's the deal, the programmer had one test case which worked fine, but she never tested anything else. I removed her test data before testing and all hell broke loose. As I had promised our customer that we would deliver that same week I made a 30+ hour weekend just to be able to deliver on monday... :sigh:
It's frightening to think about how much software there might be out there that is just "one scenario" away from blowing away a database, isn't it? :omg:
// This code will never execute, just keep it here just in case we need it.
if (false) { // Code to delete a database. }Somehow that database WILL be deleted... :doh: Actually my boss once dropped an entire product table in our customers production database (many, many years ago). Wrote a delete statement without a valid where clause without first testing the statement :) I also know a programmer who KNOWS his queries are okay so he don't need no transactions and can execute updates, deletes and inserts right away on the production database... But not without first asking someone else how you wrote a delete statement again... :doh:
It's an OO world.
public class Naerling : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
} -
IMO, even if you do have someone else unit-testing your code it's a good idea to write your own unit tests. I've always built a generic utility program that I use for that and just add onto it every time I write a significant routine. It's actually kind of fun and has resulted in handy utilities that I wound up using later! I've never used any of the "formal" unit testing stuff that are supposedly "best practice" nowadays, I've just always been in the habit of writing programs that test the boundaries of code I write. Guess I've been at this too long. -CB :-)
CodeBubba wrote:
Guess I've been at this too long.
or you just have plain, common sense. I test all of my code. However, an author doesn't edit their own work, either. That is what the editor is for. Programmers need testers. Common sense will tell you that, of course, you have to test your code, but someone else should really Unit test it for you. :thumbsup:
-
CodeBubba wrote:
Guess I've been at this too long.
or you just have plain, common sense. I test all of my code. However, an author doesn't edit their own work, either. That is what the editor is for. Programmers need testers. Common sense will tell you that, of course, you have to test your code, but someone else should really Unit test it for you. :thumbsup:
Agreed! :thumbsup:
-
In my day we called it "9 edge up".
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
Ah.. but not everybody knows that reference anymore :) I keep one on my wall at work. A rare, unpunched one, at that.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
Yeah, I know I've got one unpunched one from my days at the University of Iowa Physics Research Center. I used to have boxes of them (with programs), but I think I dumped all of them sometime in the late '70s.
Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.
-
Why do I read so much about unit testing? Is such a thing not part of every programmer's everyday life? Are not unit tests just something that is done for every little module one writes? Seriously, what am I missing?
Oddly enough, I don't at my work place. Never have touched unit tests. Mostly because my software controls industrial equipment, it's hard to simulate all the live sensor data that regulates the logic. I usually have some I/O in a test cabinet to work with, and a few customers to test at their facilities, but beyond that I have to write the entire code fault tolerant so if it fails, it logs the error for me and continues on.
-
Naerling wrote:
Nope. There's probably lots of software out there that isn't even tested at all...
You got that right. I have had to clean up more than my share of messes after people who threw code together and never ran it. I'm serious: I've seen code in our system that was obvious to me that no one put it to any kind of test *at all* as it could crash the system as soon as it was exercised. I've even seen an occasional section checked in where it was obviously not even compiled before being checked-in! :wtf: If you're writing a new code section or fixing a bug, at least run the code before turning it in, huh? I hate to say it, folks: but sometimes our work can be hard. It takes WORK. (Oops, there's that 4-letter word again!) Some people just don't need to be doing this. -CB
CodeBubba wrote:
I have had to clean up more than my share of messes after people who threw code together and never ran it
There's always some branch that's too inconvenient to test or the schedule doesn't permit to be tested. I kept track at my last job.. about 90% of the bugs were with untested code. The other 10% were a mix of unexpected consequences to changes elsewhere, and design flaws/miscommunication. At a previous job, every time I exercised an error branch in my code, I discovered a crash elsewhere in the code. We need to start making a distinction between unit tests used to test internal correctness, and those for verifying regression that test only the external interfaces and behavior of the unit. Internal-correctness tests are white-box tests, while regression tests are back-box tests. After modification, only regression tests should be expected to pass, and any internal-correctness tests should be thrown away. In my experience, if the developer who did the internal implementation writes the unit tests, they toss in a healthy dose of the internal-correctness variety, and then keep them thinking they are regression tests, undermining the usefulness of regression unit tests through excessive maintenance.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Why do I read so much about unit testing? Is such a thing not part of every programmer's everyday life? Are not unit tests just something that is done for every little module one writes? Seriously, what am I missing?
