|
First, the software driving by testing paradigm, a abortion of logic brought on by Agile programming, is not the point. Testing is the point.
But as for your smile-festooned comment:
Sander Rossel wrote: Within allotted time and costs 
I might point out that in my very simple-minded view of the world and thing in it that if the software or other product doesn't work, or worse, is unreliable, then it's overpriced even if it's free.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: I might point out that in my very simple-minded view of the world and thing in it that if the software or other product doesn't work, or worse, is unreliable, then it's overpriced even if it's free.
Then let me point out what I've already said a couple of times, software can work without unit testing.
For example, by manual testing, integration testing, smoke testing, acceptance testing...
I'm really at a loss at how you twist my words from "I unit test some code, sometimes" into "I never test and release software that doesn't work."
|
|
|
|
|
Sander Rossel wrote: I'm really at a loss at how you twist my words
Context.
In particular, take my OP[^] and see how I describe the situation.
Now, this is your thread, but from my google search on Unit Testing, first item on the left:
Quote: UNIT TESTING is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output.
Which simply means Testing. No?
Perhaps we disagree, at least in some elements of this thread, in the meaning of the subject terms. A classic cause of argument of all sorts for eons.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
W∴ Balboos, GHB wrote: Which simply means Testing. No?
No, it's a very specific form of testing.
A unit test is an automated test that tests a single method.
For example:
public int Add(int a, int b) { return a + b; }That code is never going to change and it's very simple.
Does it need a unit test? It couldn't hurt, but it probably has little added value.
Valid unit tests would be:
Assert.Equal(Add(1, 1), 2);
Assert.Equal(Add(1, 2), 3);
Assert.Equal(Add(-1, -2), -3);
Assert.Equal(Add(int.MaxValue, 1), heck I don't know, int.MinValue or something); Now my point is, that last test may or may not be something you'll think about.
If you don't, your software may still overflow despite having the previous two unit tests.
If you do, this is probably a real issue that you've already thought about when creating your Add function and you'll probably have used a long instead.
However, whether or not this code works all depends on whether it's called with such high values.
If you use this function for some invoicing, you really won't hit that overflow, but you can't test that with a unit test.
Another issue with these tests, the first test is prone to errors itself.
If you mess up the Add function and return a + a or b + b (or even 1 + a or b), this test will still pass even though the function broke.
Ultimately, you may replace your Add function with Math.Add and you'll be left with a couple of tests that you need to remove (or rewrite) as well.
So having these unit tests in place is only going to help you on the off chance that someone somehow messes up the Add function.
A smoke, acceptance or regression test will soon find that issue if it's not already caught during code review.
True, you'd much rather find it with an automated unit test, but writing so many unit tests comes at a price.
Don't forget, your tests are just more code and they'll have bugs just like the code you're testing.
It's also more code that you need to maintain, which costs time and time is money.
|
|
|
|
|
Well, the definitions I found did not talk about "automated" being part of the description.
If that's the case, "unit testing" is just testing with an extra adjective to make the speaker/writer sound more intelligent savvy up-to-date a thrall to style. Something management will shake their head to, in agreement, not wishing to appear ill-informed.
Just like the moronic overuse of the work "issue" when a real word with an actual commitment to intentions, is readily available.
Examples by trivialization or determining how it might fail - really don't prove any point. Perfection may not be achieved, but at least one does a true 'best efforts' or 'due diligence' (pick the one you prefer).
I prefer finding problems before the users do. Is it 100% effective? Not quite! But reliability has engendered trust in my "product". Embracing accountability, should I miss one, takes care of what I miss.
This place where I work does between $400 and $500 million/yr in gross business - a huge amount of it passes through my application framework. How much is a "tiny" error worth to them vs. my time?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Sander, I agree.
I do some unit testing. For classes and their methods that are easily testable, either because they are generic, have no references to anything or do simple "toolbox" stuff, like string helpers, unit converters, those kind of things.
It's fast and in many cases more easy to write a quick test then to set up some console output in the main() of the program just to call that stuff and see what it does.
but I don't force anybody to run those tests with every compile, hence many of the test never run again... They are a replacement for Console.writeline in the main program.
I am also not a big fan of that religious mvvm drama...
when we need a new value from the ui passed down to some network layer because we need to deliver that to the server and I hear an answer of "oh wow... thats hard, takes 3 or 4 days, we need several new commands here and bindings there and dont-know-what there and it will affect about 50+ unit tests..."
OMG... go away! just send that f*cking integer value over the line. if such a simple change causes DAYS of work... then this is not a programming model I want to work with. period.
I have never used any mocking framework or dependency injection...thing... man! wake up! it's just the next bunch of frameworks and libraries and biiiig big stuff you never saw, which will introduce new bugs, have it flaws... creates more troubles than it solves... you are totally giving up control of what happens in your OWN program!
that blind religious behavior is something I really see as a critical thing. Those people are trusting any totally unknown developer any some library more than their own ability to write stable, working code.
And then, that wonderful day comes where you see tears in the eyes of some developer "i don't know why it is not there! i have all the bindings, the DI is set up and all unit tests are green. I know my mocks are right in the tests. it MUST work!"...
Then I get me some coffee, maybe a coke, and don't forget the popcorn! Lean back and watch them cry. When that fine moment comes where they realise that they have totally given up control just to follow some strange ..."model"... because "it's state of the art to do things like that"... oh man...
i have apps in store (professional and with my own label), i write games, i never used such alien-stuff and all my software works fine. Sometimes I think, many of those hyped models are a doubtful try to make development easier, to have people stop thinking. because the unit tests find it anyway. dont think about object hierarchies, stop good object design, just push 15 interfaces to a constructor and write 20 factories. and at some place, somewhere, anybody will create finally a living instance of IAnything and push it to ISomething, where IDontKnowWhat will do ISee...
I write (generic) platform modules, I have in most cases MORE reusable code than the mvvm extremists but it feels like being Don Quichote sometimes...
not my world. will never be.
modified 24-Jun-20 1:59am.
|
|
|
|
|
When we write a new software I write unit tests at least for the essential parts and try to convince the team to do the same.
(And when I'm with the estimation team I add unit tests to the items to be calculated.)
But when we add something in old, grown software there's no way to get weeks of additional budget for unit tests.
And I don't see much sense in writing unit tests covering 0.1% of the code.
|
|
|
|
|
M.Vo. wrote: And I don't see much sense in writing unit tests covering 0.1% of the code.
At the very least, wouldn't that depend upon how important that 0.1% of the code is?
I mean really, on line if 100,000 can ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) up an entire application.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
What is testing? 
|
|
|
|
|
"What, me test?" 
/ravi
|
|
|
|
|
You must be MAD?
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
I once thought testing was extraneous - a luxury - something of little real value. But now I know the true value of unit testing. I'm a NEW MAN. (But you can call me Alfred.)
/ravi
|
|
|
|
|
eNewMan?
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
It's the process of debugging your application by means of getting the compiler to produce an EXE file.
Once it stops issuing ERROR messages (WARINGS are fine, you can ignore them) you're ready to ship!
"Unit" testing is just an Acronym for this process: "yoU Need It Tuesday"
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes, I remember during the good old FORTRAN or C days, they used to say that each subroutine or function is to be tested by giving several valid inputs, and several more invalid inputs, and then the response seen.
For example, for a numerical argument, give input within range and at the boundary (for valid inputs), and outside range, one-off inputs, alphanumeric, decimal, integers, negative numbers, etc. (for invalid inputs).
Similarly for strings.
Faintly remember that it used to be called Equivalence Group Testing. Quite fail-proof. Not sure whether it is still being used.
|
|
|
|
|
Nowadays, that's something your customers do it for you, for free.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
