|
When I was doing FORTH programming, each verb was its own unit test. No special coding required, just load up the stack, execute the verb, and check the result stack and variables touched.
A friend and I did some awesomely fast coding on a system I estimated to take 9 months in only 6 weeks because we were able to test everything as we went and when we zippered our independently developed code together, it all worked.
It was a realtime system and single step debugging was not an option, so it all had to work on virtually the first try.
I loved coding in FORTH which allowed you to intermix high level code and low level assembler code seamlessly.
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.
|
|
|
|
|
A very underrated language
|
|
|
|
|
That is because it was not created by an academic in an academic setting and it wasn't drummed into heads of students as the only way to program.
We have lost the diversity in computer architecture, in operating systems and in languages.
We have the cookie cutter approach now: Intel 80xx6 for learning architecture, Unix for operating systems and C for languages.
One could go to ITT Technical Institute for this kind of training.
We have un-thinking coding robots coming out of colleges.
|
|
|
|
|
...they spend more time writing unit tests than they do the actual code?
|
|
|
|
|
Yeh, if you include writing AND debugging the live code.
I find if I write a bunch of good unit tests I end up spending significantly less time debugging the live code.
The beauty of unit tests is that it is such a narrow and controlled environment that squashing bugs is way quicker.
modified 4-Aug-15 16:48pm.
|
|
|
|
|
Totally agree, and of course, one they're written, they can be re-used so in the long term it will save time. Damn short-termism.
|
|
|
|
|
Not entirely. Things change and this means having to rewrite/position code and change the tests for it too. If it doesn't change, then you don't need to keep testing it. It could break due external influences, but then that's outside the scope of unit testing and you probably won't have a test for that case.
Personally I think its useful, but not as useful as general opinion thinks.
Regards,
Rob Philpott.
|
|
|
|
|
I have never written less buggy code, because I used Unit Tests.
Unit Tests are used to make sure that your code process was not broken by either you or another developer down the line somewhere. This is especially used with automated build,test, and deploy systems.
Again, I don't practice test driven development. Not a member of that camp.
|
|
|
|
|
...you spend more time fixing odd, hidden and regression bugs than they do the actual code?
cheers
Chris Maunder
|
|
|
|
|
As a business we do unit testing. As an individual I don't - although I suspect that will change as it is forced upon me. In theory I like the idea of it - in practice I get to see lots of code which has been mangled to death in order to pass tests, ease mocking and enable IOC
|
|
|
|
|
RugbyLeague wrote: lots of code which has been mangled to death in order to pass tests, ease mocking and enable IOC
Quite! And that goes against the KISS rule.
Regards,
Rob Philpott.
|
|
|
|
|
I won't test anything U knit, either.
modified 6-Aug-15 18:22pm.
|
|
|
|
|
Everything we release to the evil ones (users) is tested.* Things are tested in their context: at function level, class level, and application level. Experience has shown that testing all the small pieces is no substitute for testing the real thing when they're lovingly cobbled together.
Make up new names for old ideas. Pretend these are new strategies if it makes you feel special. It's a simple bottom line:
When you let that thing loose, from someones perspective it's got your name on it. Whatever that's worth to you . . .
*Unlike modern HDD's which are tested via the RMA strategy: cheaper to replace than to test.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I am agreeing with you loudly
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
W∴ Balboos wrote: Everything we release to the evil ones (users) is tested.
I could not agree more.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
However, it can be impractical in application.
I have been on many software teams, and with many companies, and each one handles/views Unit Testing differently. My life experience with Unit Testing has been, that you try your best to have your team write effective unit tests for the important items/processes that need them, in the time allotted.
If you are in an aggressive Agile environment, this can be a daunting task, just like writing SDDs for everything you do - Nice idea, ain't gonna happen.
|
|
|
|
|
They're only as good as the programmer who writes them!
I've worked with someone who unit tested a function (all tests passed), put it in production, and got me a few hours overtime because everything collapsed!
That same programmer unit tested some code and told me "nothing is wrong with this code because all tests passed" while clearly something was wrong (a multi threaded timer that went off 3 milliseconds early, unit test that!)...
This programmer also believed unit testing solved all of his problems (and in a way it did, because I was the one who had to solve them).
And then I've seen code that isn't unit testable.
A function with some 100 lines of code and numerous if- and switch statements?
Such code should never see the light of day, but there are bad programmers and such code is produced.
Anyway, unit tests aren't going to help you there (only fear and caution will).
I'm not saying unit tests are worthless, they saved my ass a couple of times.
They're just not worth getting all religious over (something I see far too often with unit testing).
Writing clear and readable code and using your common sense is so much more effective than unit testing.
|
|
|
|
|
You must know what you test. Esspecially timing, like delays and multithreading cant get tested.
But testing for functions as save/restore and crypto is fine.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
I actually just fixed a bug from a release I did last week. It was a functional bug that unit tests would not had picked up. It seems a functional test is more of what I needed.
|
|
|
|
|
Sander Rossel wrote: This programmer also believed unit testing solved all of his problems (and in a way it did, because I was the one who had to solve them).
That made me chuckle 
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread 
|
|
|
|
|
I've been in a continuous delivery environment where we lived and died by unit tests. Assuming perfect unit tests with 100% coverage, we'd never release a bug, but since this is NEVER the case, balance is needed.
Overall, for me they are worth the investment in the long run and I write them whenever feasible.
|
|
|
|
|
The problem with unit testing (or any other type of automated tests) is that if the structure of your code changes for any reason (i.e. new requirements) then all the unit tests have to be rewritten. The time invested in writing the tests, is probably more than the time the tests save by finding bugs.
Its probably better for stuff that doesn't change a lot (like APIs)
|
|
|
|
|
That's not really true. Almost every code base I have worked on has evolved to do things it was not initially designed to do. Unit testing allows you to make sure that the original code objectives still work after you make changes, and the unit tests are adjusted (if necessary) when new features/functionality is added. [And the new features/functionality get their own new unit tests.]
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
maybe you're doing automated testing, not pure unit testing then.
Unit testing implies that every function has a unit test.
But even automated testing has the same disadvantage when the requirements change frequently.
|
|
|
|
|
whenever I developed a class library I add an unit test. After all, you want to check your code with something.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
