Unit testing
-
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?
Gary Huck wrote:
Why do I read so much about unit testing?
Because software was buggy, and this was a way to do something fancy (make little lights turn green, some people tied unit testing to actual an actual traffic light or siren), and it was a way to automate testing so it was repeatable. Essentially, it gives everyone the illusion that stuff is working.
Gary Huck wrote:
Are not unit tests just something that is done for every little module one writes?
No. Repeatable testing is as hard, if not harder, than writing the program itself, especially when you throw in mocking objects because the data sources come from places like RSS feeds, web services, databases, etc., things that you don't want to necessarily have a live connection to every time you run your tests.
Gary Huck wrote:
Seriously, what am I missing?
Having worked on a project that failed due to bugs? Marc
-
There's a difference between doing something, doing it properly, and doing it so it is measurable, recordable, and properly covers your ass should the breasts go skywards.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
ChrisElston wrote:
should the breasts go skywards.
Till now, I actually thought that was a good thing (associating skyward breasts with firm, young breasts that are...oh, nevermind...) I'll just shut up now :laugh:
Full-fledged Java/.NET lover, full-fledged PHP hater. Full-fledged Google/Microsoft lover, full-fledged Apple hater. Full-fledged Skype lover, full-fledged YM hater.
-
There's a difference between doing something, doing it properly, and doing it so it is measurable, recordable, and properly covers your ass should the breasts go skywards.
Every man can tell how many goats or sheep he possesses, but not how many friends. Shed Petition[^]
ChrisElston wrote:
breasts go skywards
Tits up still sounds better. Just saying... :)
-
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?
Unit testing should be done by someone else, IMHO. Someone who did not write the program. I, and many others, like to do our little mini unit tests, in order to sign off on the code for proper testing. My two cents.
Gary Huck wrote:
Why do I read so much about unit testing?
People like to hear themselves talk and they like to see their names in print. Why else are their millions of pages on the web for anything from cooking to debugging knuckle heads. No one is saying anything new, different or beneficial, that hasn't been said already. How many articles do you really need on programming fundamentals? One.
-
Unit testing should be done by someone else, IMHO. Someone who did not write the program. I, and many others, like to do our little mini unit tests, in order to sign off on the code for proper testing. My two cents.
Gary Huck wrote:
Why do I read so much about unit testing?
People like to hear themselves talk and they like to see their names in print. Why else are their millions of pages on the web for anything from cooking to debugging knuckle heads. No one is saying anything new, different or beneficial, that hasn't been said already. How many articles do you really need on programming fundamentals? One.
I think unit-tests ARE the original implementers responsibility. Unit-tests is fundamental white-box verification on a very fine scope. Once the individual units are combined and a product is created, someone else should verify the product as a black-box for correctness and completeness. Unfortunately, I think this is one of many areas in software engineering where the vocabulary is not well defined and agreed upon, therefore everyone uses the same terms to mean different things.
All of my software is powered by a single Watt.
-
I think unit-tests ARE the original implementers responsibility. Unit-tests is fundamental white-box verification on a very fine scope. Once the individual units are combined and a product is created, someone else should verify the product as a black-box for correctness and completeness. Unfortunately, I think this is one of many areas in software engineering where the vocabulary is not well defined and agreed upon, therefore everyone uses the same terms to mean different things.
All of my software is powered by a single Watt.
I guess you are correct about vocabulary. I don't think that my "white-box" verification is unit testing. I guess it means different things to different people/shops. :)
-
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?
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(); }
} -
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?
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!! >>
-
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:
There's probably
No. There IS! You made a very good point, here.
-
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?
It might be due to a change that our industry is currently facing. No other industry than ours can decorate a new version with a huge list of bug fixes and call that a feature! Imagine your car is ready from maintenance and the report says "The breaks are now working when the car drives downhill also"... Someone, sometime in some place must have realised that shipping quality software with little bugs (I don't say "no bugs" because that is not achivable) is an attribute that gives you a better position in business competition. Better testing is seen as a (or one) cure to that. For us as developers that means unit testing as a tool and practices like test driven development, pair programming and / or scrum / kanban. The point why there is so much talk about unit testing IMHO is that it is relativley new to us, it is - as others already mentioned - sometimes hard to do if it should be done right and even though the management wants less bugs, they sometimes are not willing to spend the extra money that is needed to educate us in writing (good) unit tests or allow us the extra time that is (not always) needed to write the tests. Regs, Chris
-
ChrisElston wrote:
breasts go skywards
Tits up still sounds better. Just saying... :)
-
Unit testing should be done by someone else, IMHO. Someone who did not write the program. I, and many others, like to do our little mini unit tests, in order to sign off on the code for proper testing. My two cents.
Gary Huck wrote:
Why do I read so much about unit testing?
People like to hear themselves talk and they like to see their names in print. Why else are their millions of pages on the web for anything from cooking to debugging knuckle heads. No one is saying anything new, different or beneficial, that hasn't been said already. How many articles do you really need on programming fundamentals? One.
-
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:
