Unit testing
-
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?
