Quantcast

Maximum PC

It is currently Wed Oct 22, 2014 1:15 am

All times are UTC - 8 hours




Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Wed Jul 06, 2011 4:18 am 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Gadget wrote:
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 :)

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? 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).

Quote:
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?

Quote:
What are the options? To not fix things? To not be proactive?
There isn't always an option. If it is poor, but works, you are going to have a hard time justifying fixing it. I know it makes sense to. You know it makes sense to. Doesn't always matter what we know though.


Top
  Profile  
 
 Post subject: Re: Why Windows 8 will still disappoint me
PostPosted: Wed Jul 06, 2011 10:10 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
CrashTECH wrote:
Gadget wrote:
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!

CrashTECH wrote:
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... ;)

CrashTECH wrote:
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.

CrashTECH wrote:
Quote:
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).


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.