|
Ha! And my silly me is trying to get up a CI with unit test automation and code inspection.
(Still working on the unit tests though  )
How come i didn't know that it's not my job ... 
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: How come i didn't know that it's not my job
You're such a naive dev thinking that you have to test.
Here's the latest
Mic-Drop Coding Methodology...
Step 1 : Write Code
Step 2 : Drop code -- I'm out!
|
|
|
|
|
Testing is pointless. By the time you're done writing the code to meet the requirements, the requirements change, and the changes remain a closely held secret until the day the code is scheduled to be delivered\submitted to be tested.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: By the time you're done writing the code to meet the requirements, the requirements change
Oh, silly you. You're talking about real software that exists in the real world.
Testing is only for vaporware. That way we can('t) be sure we got it right and wrong.
|
|
|
|
|
Those are probably Heisenbugs: they probably don't exist until some eejit tests for them.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I assume that you are joking.
If there were any truth at all to what you are saying, then your software architecture certainly should be revised. Sure requirements change, but not into a completely different problem. The basic task is still the same, and thre great majority of the modules stay unchanged. Those that are modified, are usuall functionally extended, or, for user/protocol interface modules, mostly reorganized. If every requirement change invalidates all tests for all modules and subsystems, then I would be scared to use your code for anytning at all.
Even if you are joking (which I certainly hope): Too often you see arguments very close to the one you make, but said in dead earnest. "This is just a temporary solution". "The testing procedures are not yet updated to account for the changes" etc. We should be very sensitive to that kind of arguments, and immediately set down our foot.
|
|
|
|
|
I assume you're referring to Unit Testing, not "I ran it and it works on my machine"
Based on my experience the majority of software shops don't do testing, meaning it's not a required part of the development experience.
I just started a new position.. no unit testing.
Last position... HAHAHA - Testing?? Are you kidding??? Who's got time for that?
Previous position.... Some unit tests in some teams
Previous position.... What's a Unit Test???
Previous position.... I'm working 60+ hours/week... I don't have time for that...
Previous position.... Looks like it's running... Send it to QA.
.
.
.
and so on.
I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: I think that there's a stigma associated with Testing that the primary purpose of a developer is to write code, and testing isn't code.
Yes, but the stigma of producing terrible code that literally crashes in production is far worse.
The best kind of testing (and software development) occurs when a developer (no matter the level) literally thinks:
I _own_ this software and it represents me.
However, in corporate environments -- yes I work in one too -- this does not occur for many reasons:
* dev is ignored anyways
* dev has so many layers of management no one ever really talks to dev anyways
* project is boring
* project is doomed for other reasons anyways
* there were no actual requirments created anyways, so anything could be accepted (screw it)
* people in charge who are driving the project don't know anything about actual software dev anyways
Too many more to list here.
|
|
|
|
|
Ok drop the mask who are you of my colleagues? Knock the Imperial march on the desk so I can recognize you!
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
den2k88 wrote: Ok drop the mask who are you...
|
|
|
|
|
What is this "requirements" you speak of.
|
|
|
|
|
urlonz wrote: What is this "requirements" you speak of.
It's funny...as long as it is someone else trying to hit a unknown target.
Sales: Users want a thing.
Dev: Uh, can you describe it to me? Let's meet and gather some requirements.
Sales: Can't you just build it? Are you stupid or something? You aren't really a dev are you? I asked Bill-Bob in Tech support who knows Python and he said he can build it for me in 2 days.
Dev: Billy-Bob is a genius!! Go for it.
|
|
|
|
|
How many times have I had this conversation. Real-life conversation between me and a member of sales as we sat down to lunch one day:
Sales: Hey, how is the Project X thing going along?
Dev: What's Project X?
Sales: You know, Project X. We've been selling it over the last month.
Dev: Never heard of it.
Sales: Geez, man. We have a client coming onboard next week.
Dev: I guess you should explain to me just what you've been selling.
Sales: I don't have time for that, but you need to get on that right away.
|
|
|
|
|
And so it goes... Laughing or I'll cry 
|
|
|
|
|
raddevus wrote: The best kind of testing (and software development) occurs when a developer (no matter the level) literally thinks:I own this software and it represents me.
I disagree. I don't consider myself the owner of any of the code I write. Author, yes, owner, no. I've seen too many cases where having devs think they own code leads to egos being attached to the code, which creates worse roadblocks to getting it fixed than anything else.
I just test the code I write so whenever there's a problem, I know it'll be in someone else's code instead of mine. Helps me relax at night  .
Oh, and test data? A useful tool, but not a sufficient one. It misses sooo much, and all the bugs that cause catastrophic failures are almost always in untested parts of the code. As devs, its our job to not leave parts of the code untested. Period.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Good discussion and viewpoint.
patbob wrote: I don't consider myself the owner of any of the code I write.
I have a conflict with this but I lean toward ownershipo because I have created numerous projects that I am the requirements gatherer, system analyst, developer, tester and deployer. I own it 100%.
You can see the app I created this way on multiple platforms:
Swift (iOS) app in app store : CYaPass on the App Store[^]
Android app in Google Play ==> CYaPass in Google Play[^]
As a windows winform app: ==> C'YaPass: Forget All Your Passwords | Get C'YaPass[^]
and even as a JavaScript, HTML5, Canvas app -- no install required, try it in your browser:
C'YaPass: Forget All Your Passwords | WebApp[^]
So my ownership ideas come from that. And I know dev's egos go crazy at times, but without ownership people just don't give a crap how things turn out generally. Just an opinion of course.
patbob wrote: s devs, its our job to not leave parts of the code untested. Period.
I know. You can't do everything. Except, when you have to.
|
|
|
|
|
At my last position, we were responsible for making sure the code compiled, ran without exceptions, and updated the UI as expected. At that point, we handed it over to Q/A who had test cases to run the code against. We had to do this because most of the changes were UI changes, and you can't really automate them. All tests were run with a video capture so we could re-run the videos to see what the user did to make the code fault. It worked pretty well.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Same with me on my last pos. And, the QA team was in India ( Don't ask me I didn't decide that) so after a check in we had to wait 24 hours for a testing cycle.
I once knew a guy who sat next to me, and his idea of testing was to open a DOS Command Prompt, CD to the folder the app was in, and run the EXE, which then opened the app in Windows (It was a Windows Forms app). "It runs, so it's OK"
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: "It runs, so it's OK"
Which is only slightly more useful than, "It compiles. Ship it!"
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Interesting. I have always eaten my own dogfood wherever practical and try to get everyone around me to do the same. Most larger shops have had decent QA but there is no point in passing untested code to QA in the hope that it'll scrape by - it won't.
I really don't understand the notion of cobbling code to together and passing it up the chain without, at the very least, checking to make sure it does something along the lines of what was required.
[EDIT} Perhaps it's because I come from an engineering background. You would not even consider letting a creation out of the shop without thorough testing. Perhaps that's what needs to be ingrained into the kiddies at uni.
modified 5-Jan-17 11:17am.
|
|
|
|
|
R. Giskard Reventlov wrote: I really don't understand the notion of cobbling code to together and passing it up the chain
I can't get inside that mentality either. It's quite terrible.
I think it's either:
1. complete Ego-driven dev with a seasoning of laziness
or
2. complete Lazy-driven dev with a seasoning of ego.
|
|
|
|
|
|
I fit into option one: The ego will not allow me to deliver crappy code - the QA (users) are anally retentive, pedants who delight in sending back a bug report.
Laziness - I loathe writing the same code twice.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Actually, that's a really great personality description of most devs, I hope.
I agree 100%.
And you've raised an important point about some testers who have a chip on their shoulder and just bug report on the most ridiculous details. Great stuff.
|
|
|
|
|
Sereiously, I've seen VERY few unit tests where I didn't think: There's no way this is EVER going to fail!
And then I wonder: Why did you (not me, but the programmer who wrote it) waste your time writing the test (and running it over and over again)?
And why do managers insist that you write tests for every tiny detail that can't possibly go wrong?
I'm not against unit testing as such, but I think it's WAY overrated.
To be fair, I HAVE seen tests that were actually were nice to have (and written one or two myself) - but mostly waste of time in my opinion! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
