|
Well, you might ask She-Who-Must-Be-Obeyed: "Didn't you marry me because I was Peter Pan ?"
Or, you might remind her that there are other vices the male-beast is susceptible to that are far worse.
cheers, Bill
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it. A few hundred years later another traveler despairing as myself, may mourn the disappearance of what I may have seen, but failed to see.» Claude Levi-Strauss (Tristes Tropiques, 1955)
|
|
|
|
|
'The good software development manifesto', to be precise. Now that's sweet. So sweet that it makes me ill.
Quote: This means you need tests to prove your code works, and you need processes around your code that produce data that prove you’re not reverting code.
In no place and at no time a test has ever proven anything.
Quote: Coding is important, but it is important in the way an engine is important in a car. The best software developers have empathy for others who have different roles, interests, and stresses on them.
<cynism>The best software developers are complete masochists and have no empathy for anyone, including themselves. They will gladly say 'I told you so' and rub in your mistake until your last breath.
Quote: One of the first “languages” I learned was 8086 assembler. That was as close to the metal as I ever came. If we were really just “programming computers,” we would all be writing bytecode. Computers understand it best. But we’re writing in a “compromise” language that other people can understand and that can be translated to something the computer understands.
Oh yeah. That's it. That's why we have so many who will never grasp what stuff like type safety or object orientation are about. You know, those poor souls who always are looking for that silver bullet that will finally make them successful.
Quote: Conway’s law predicts that your software is doomed to reflect your team and its communication structures. Process is the structure of that communication.
Then Conway's law also explains why a single good developer can succeed where entire teams have failed. A case for the 'Cowboys' and the 'Ninjas'.
Quote: If you believe that people’s ethnicity, gender, or whatever is a good way to judge their skills or what they have to teach you, you’re limiting your own development as a software developer.
Shirley that does not mean having to tolerate the speech bubbles from the management, marketing or sales? Or anyone else who could not program the escape routre out of a wet paper bag?
Quote: A logical theory tends to have a means by which you could be proven wrong. If it doesn’t, it probably isn’t a very good theory.
Oh Gawd! Science would be in deep trouble if that were true. It's, for example, impossible to prove the nonexistence of something. Instead, a theory should make predictions which then can be validated or falsified.
I need a perfect, to the point answer as I am not aware of this.
Please don't reply explaining what method overloading is
|
|
|
|
|
CodeWraith wrote: In no place and at no time a test has ever proven anything.
Then write better tests.
|
|
|
|
|
I cannae change the laws of logic!
I need a perfect, to the point answer as I am not aware of this.
Please don't reply explaining what method overloading is
|
|
|
|
|
In this case im on OP's side but also on yours.
A test proves if a predefined result is returned after inserting a predefined input.
So yeah, on one side the OP is right by saying test do not prove if the code works, but they prove if the code works under certain circumstances.
That is why i say, tests give us a result about how confident we can be in our code.
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
HobbyProggy wrote: but they prove if the code works under certain circumstances.
That is why i say, tests give us a result about how confident we can be in our code.
That's great stuff!
|
|
|
|
|
You can't always simulate real world conditions. You are always missing one factor... the DUA (dumbest user available)
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Unit tests aren't trying to emulate real world conditions, they are meant to test small isolated pieces of functionality. Failure to predict what real users might do is down to standard testing.
|
|
|
|
|
You can prove the test works, but the code being tested could still be cheating.
Sin tack
the any key okay
|
|
|
|
|
Which brings us back to....write better tests.
|
|
|
|
|
F-ES Sitecore wrote: Then write better tests.
Heh, you replied the same with my rant on the Insider News. 
Personally, I prefer to avoid unit testing. Success/failure is a completely subjective phenomenon. Some users will say the app works as intended, others will not. What's the difference? Surely not the unit tests, they pass under both conditions. The difference is hierarchical -- the higher you go in the management chain, the more probable the "it's not working" response. The lower you go in the user chain, the more probable the "it's broke" response because the user doesn't understand basic computer operations.
Ultimately, the goal of a unit test is to provide some confidence that you can build higher level functionality on low level units of code. The goal of building higher level functionality is so you can build even further higher level functionality. Ultimately, that results in the application. Given that only a narrow band of people in the hierarchy of management/knowledge will actually say "it works!" only goes to prove that unit tests, if not downright useless, are incredible cost/time wasters.
Marc
|
|
|
|
|
Marc Clifton wrote: Ultimately, the goal of a unit test is to provide some confidence that you can build higher level functionality on low level units of code.
I disagree entirely. The purpose of a unit test is to prove that unit of code works, that it behaves as you want it to. That given a certain range of inputs you get the desired outputs. If you write tests that don't explore boundary testing and different scenarios then your tests *are* useless and you shouldn't do them. When you build functionality on top of that code then that introduces more logic etc so requires its own testing. Of course that code isn't going to automatically work just because the code it uses does. If that's what you think unit tests are for then it's no surprise you don't see their value.
Unit tests come into their own when refactoring code or amending code to encompass new functionality, especially when working in a team. Unit tests should add confidence that changes you are doing don't alter the previous logic in any way, and if it does alter that functionality you should be told of such by the failing tests which then enables you to have a discussion around how you come up with a solutoin that satisfies all parties.
|
|
|
|
|
F-ES Sitecore wrote: I disagree entirely.
There are times when I start off writing a sarcastic/humorous response and then discover that there are some half-truths come out of it, granted, based on faulty logic/reasoning. 
F-ES Sitecore wrote: If you write tests that don't explore boundary testing and different scenarios then your tests are useless and you shouldn't do them.
Well, not necessarily. Sometimes I write a unit test because it's a convenient way of setting up a test fixture for testing that code works with normal parameters. I may or may not go back and do boundary testing later on - it all depends on whether I can guarantee that the inputs are always valid for various reasons, including that the caller is doing validation.
F-ES Sitecore wrote: Unit tests come into their own when refactoring code or amending code to encompass new functionality, especially when working in a team.
Yup, and the irony there is I did an introductory demo of unit testing for the team I landed in, as nobody even knew how to write unit tests, let alone use the tools Visual Studio provides. 
Marc
|
|
|
|
|
I have often found that the best unit tests are, in reality, actually using the application that you are building to attempt to achieve its intended goal.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
CodeWraith wrote: In no place and at no time a test has ever proven anything.
Plans are useless in wartime, planning is not. The same goes for testing.
A unit-test is something that tests the assumptions about a bit of code in an isolated environment. Those assumptions (or requirements) come from the specs, which may alreay contain errors. Even if you can guarantee that every nail and plank is tested, does not mean that nothing can go wrong when putting the parts together.
I'd have to agree with you on some other subjects as well;
Someone else wrote: If you believe that people’s ethnicity, gender, or whatever is a good way to judge their skills or what they have to teach you, you’re limiting your own development as a software developer.
It is not what we believe, but what we DO.
Humans (and animals) categorize things as they encounter them, because putting them into a "known box" is an evolutionary advantage. If you encounter a lion and it eats one of you, then it would only be logical to be fairly acceptable to be wary of any other lion.
Whine about it all you want, psychology nor biology will change just to satisfy the perfect safe-space universe. And your gender has nil impact on my code - and no, I will not include a list with 27 types of genders in my database. You are seriously limiting your own growth if you keep living in a world of make-believe.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: If you encounter a lion and it eats one of you, then it would only be logical to be fairly acceptable to be wary of any other lion.
Or at least to make sure that you are faster as other ones  
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
..you can call me prejudiced, but we will not go hunting together
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Plans are useless in wartime, planning is not.
Erwin Rommel, if I'm not mistaken. So tests are useless in wartime, testing is not?
But ok, I sure have better things to do than testing or planning when I see the light brigade charging at me.
I need a perfect, to the point answer as I am not aware of this.
Please don't reply explaining what method overloading is
|
|
|
|
|
No plan survives contact with the enemy!
So, no test survives contact with........management?
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
plan --> enemy
test --> user
I need a perfect, to the point answer as I am not aware of this.
Please don't reply explaining what method overloading is
|
|
|
|
|
I find users to be much less adversarial, though that was my draft version :p
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Hey, even better: For the first time my signature appears.
I need a perfect, to the point answer as I am not aware of this.
Please don't reply explaining what method overloading is
|
|
|
|
|
Your plans may not be watertight, just as testing does not prove that there are no unknown errors in the application.
Still you will need some planning to prevent complete chaos. Not testing simply because it does not guarantee anything is the same accepting defeat.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Heh. That sounds like my rant.
And ironically, F-ES Sitecore wrote exactly the same reply.
Marc
|
|
|
|
|
You need a map and a shovel to find them...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
