After all, you can't expect to get rich working for a companies that cannot afford to fix their software.
You can't get rich working for somebody else anyway
Define rich... =)
It depends on the industry, person and a whole bunch of other factors. The old Forbes quote was that "3 billionaires and 3,000 millionaires work at Microsoft"; I don't think they were all rich starting out. When JWZ was working at Netscape, he wrote a small greeting app so that when he arrived at work each day he would see something like...
Netscape stock is worth $47.75 today.
Your have xxx stock options currently worth $675,393 due in 239 days.
SO DON'T BE AN IDIOT AND QUIT YOUR JOB!
My point is this: If you have a unit test that is not written correctly. The code passes, but is in correct. How do you know? How to you VERIFY your test is right?
Before addressing a specific example, I'd like to point out that this issue extends to any type of testing. At this point you're talking about program verification which is a really difficult problem in CS/SE. Dijkstra did some interesting work in this area. Of course, the problem with program verification is (frankly) there aren't enough engineers talented enough to do it and the time it takes to perform the verification pushes it out of the reach of anything but the most advanced/critical projects. When I was at Boeing, a tech-fellow and USC professor James Alstad covered Dijkstra's method and I swear to you that out of 100+ people attending, there were probably fewer than five people who actually understood him.
Maybe this is a research area for you...
I know you say you just re-do it, fine, but how do you know? Especially if it is a data thing? Say I set up a test to make sure I can't set an inventory value negative, or whatever (or is this not a valid thing to unit test? I admit, my experience is rather small).
I'm assuming that you're referring to data in a database or some other type of long-term datastore. Yes, you can do this type of testing using unit tests. Let's assume that you have a trigger setup to prevent this type of value from entering a database. You could have the unit test attempt to insert an invalid value and see if the DBMS responds as expected.
This specific example is more appropriately done using a rules engine (I mentioned writing a rules engine in another thread... or maybe it was here; I believe DJSpin80 is writing one now) which will provide a general framework for data validity (eg maybe test that the value is between -5 and 5, inclusive). You'd still want to unit test your rules engine to make sure it is working properly.
Generally, if you're having trouble writing a unit test for a piece of code, there is a very high probability that the code in question is badly written. It needs to be refactored.
I thought the point was you wrote a test based on input and output, why would it matter what was in the code?
Yes and no. A unit test is a blackbox test, but it also gives you an opportunity to test the interface. If you're having trouble writing unit tests for a piece of software, usually either the interface should be refactored or the function/method is 'too busy' (ie someone should have written several functions instead of just one).