Skip to main content
50 events
when toggle format what by license comment
S May 18, 2019 at 10:17 history notice added Thomas Owens Historical significance
S May 18, 2019 at 10:17 history locked Thomas Owens
Jul 15, 2016 at 2:09 review Reopen votes
Jul 17, 2016 at 9:07
Sep 11, 2013 at 13:04 review Reopen votes
Sep 11, 2013 at 13:43
Jan 18, 2013 at 22:03 history unprotected yannis
Jul 29, 2012 at 12:03 comment added nubm @AndréParamés You obviously haven't read that study at all. "The increase in development time ranges from 15% to 35%. From an efficacy perspective this increase in development time is offset by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM."
Jul 27, 2012 at 18:58 comment added Erik Reppen Well, MS is legendary for code bloat and quantity over quality approaches to issues. Everything I've seen from IBM that's been web-related, has been horrifying. I think MS is shaping up and certain departments have their stuff together, but I would definitely look to case studies at places that most closely resemble your organization. IBM has been living off of mostly-unwarranted IT-brand-loyalty for decades now.
Jul 27, 2012 at 10:23 history closed gnat
Walter
dan_waterworth
ChrisF
not constructive
Jul 27, 2012 at 10:16 comment added André Paramés @nubm: Well, that's not what the case studies have found.
Jul 27, 2012 at 10:12 comment added André Paramés @ErikReppen: care to expand? Are they worse than the average development team? (I frankly don't know).
Jul 26, 2012 at 23:38 comment added Erik Reppen @AndréParamés I wouldn't look to Microsoft or IBM for best coding practices or case studies that will be relevant to sane development teams. Well, certainly not in a general department unspecific sense anyway.
Jul 26, 2012 at 19:27 answer added Erik Reppen timeline score: 8
Jul 26, 2012 at 13:55 comment added nubm @André I consider TDD as positive especially in the context of the whole development cycle. But when the developer is at the start of a new project he should take into account it will cost more time. It will hit his immediate productivity and it will cost his or his employer money.
Jul 26, 2012 at 10:21 comment added bobby An interesting related read googleresearch.blogspot.in/2006/06/…
Jul 26, 2012 at 9:36 comment added André Paramés @nubm: According to case studies at Microsoft and IBM, unit tests actually speed up your total development time. stackoverflow.com/questions/3756796/…
Jul 26, 2012 at 8:59 comment added nubm Yes it will slow you down. It can consume up to 1/3 of your development time. So you should decide what to test and what not to test.
Jul 26, 2012 at 0:13 comment added David van Dugteren @JeffO In my opinion, there's a difference between covering unit testing at University in an academic environment to covering unit testing in a production environment. In university the Software engineering courses will teach Unit testing, but to really grasp the usefulness requires experience.
Jul 25, 2012 at 22:24 answer added Aadaam timeline score: 1
S Jul 25, 2012 at 19:06 answer added Loren Pechtel timeline score: 4
S Jul 25, 2012 at 19:06 history made wiki Post Made Community Wiki by Loren Pechtel
Jul 25, 2012 at 16:42 answer added KeithS timeline score: 5
Jul 25, 2012 at 15:38 comment added njr101 "unit tests are for catching regressions". No. Automated tests are for catching regressions. Regressions invariably require the same tests to be run many hundreds of times so it is worth the effort to automate them. Unfortunately many of the responses and comments on this question are really dealing with the issue "Are automated tests that helpful?". Unit tests may be a form of automated test but they have a completely different focus. I certainly consider automated tests to be worth their weight in gold, but that shouldn't be used as an argument to justify unit tests (or TDD for that matter).
Jul 25, 2012 at 13:56 answer added DefenestrationDay timeline score: 1
Jul 25, 2012 at 12:32 comment added Alan Barber I would suggest visiting DimeCasts.Net and watching their video series on Unit Tests and Mocking. You will learn a lot by seeing code in action.
Jul 25, 2012 at 10:27 comment added sleske -1 Sorry, I'm all for good arguments, even if I do not agree, but this is just wrong. No one claims "unit tests are for catching bugs in new code", so that's a straw man - unit tests are for catching regressions. And the Dijkstra quote is taken out of context - the context is that testing is pointless if you have a formal specification of your problem.
Jul 25, 2012 at 9:44 answer added Kaz Dragon timeline score: 2
Jul 25, 2012 at 9:34 answer added Tjaart timeline score: 4
Jul 25, 2012 at 3:19 answer added Yusubov timeline score: 4
Jul 25, 2012 at 0:48 answer added Daniel Pryden timeline score: 48
Jul 25, 2012 at 0:47 comment added Bill K Unit tests are questionable--Great for dynamic langauges, less useful the more strict your language is, but DO BUILD TESTS. They don't have to be unit tests, but you really should have integration tests you can run with JUnit, those are very useful.
Jul 24, 2012 at 23:59 comment added osdamv agaisnt legacy systems, for example a very old stored procedure that take 12 argumenst a you want to migrated to nhibernate, that things save the live
Jul 24, 2012 at 23:52 comment added JeffO How exactly did you cover unit testing without writing any unit tests? Was this one of those "grade yourself" or "design your own curriculum" schools?
Jul 24, 2012 at 23:34 comment added PhD Cont'd: Have a look at Design Driven Testing - amazon.com/Design-Driven-Testing-Smarter-Harder/dp/1430229438/…
Jul 24, 2012 at 23:33 comment added PhD As others have noted you can do "dum unit testing" - lots of tests for various cases for that particular module. If you do "design driven testing" i.e. derive test cases "from design" (rather than design from test cases as in TDD) you'll actually write "less test cases" but those that are more meaningful. It's not necessary to write 20 test-cases for 2 methods, when 5 of them will never occur in the system by design. Or to write tests that cover more than one module, saving duplication.
Jul 24, 2012 at 22:35 history tweeted twitter.com/#!/StackProgrammer/status/227894790241517568
Jul 24, 2012 at 22:12 comment added Adam I would like to just say the other side of this is some places require them as practice. I am at a place now that we are not allowed to check code in unless it is covered under unit tests. So it is a point to note that even if you may not believe in them, you may be required to do them down the road. I think it is a useful skill to learn and have in your arsenal. I many times will find little bugs and mishaps in my code from doing the tests, almost a little QA session with yourself.
Jul 24, 2012 at 22:07 history edited Jane Doe CC BY-SA 3.0
deleted 4 characters in body
Jul 24, 2012 at 22:00 answer added k.m timeline score: 38
Jul 24, 2012 at 21:27 history protected maple_shaft
Jul 24, 2012 at 21:13 answer added Heath Lilley timeline score: 60
Jul 24, 2012 at 21:04 answer added P.Brian.Mackey timeline score: 4
Jul 24, 2012 at 20:45 history edited rjzii CC BY-SA 3.0
hopefully improved grammar
Jul 24, 2012 at 20:41 answer added rjzii timeline score: 41
Jul 24, 2012 at 19:52 answer added Random42 timeline score: 3
Jul 24, 2012 at 19:47 history edited gnat CC BY-SA 3.0
spelling, formatting, personal stuff cleanup, tags
Jul 24, 2012 at 19:46 answer added Telastyn timeline score: 25
Jul 24, 2012 at 19:34 answer added Stefano Borini timeline score: 11
Jul 24, 2012 at 19:32 answer added KeesDijk timeline score: 124
Jul 24, 2012 at 19:30 answer added Mason Wheeler timeline score: 94
Jul 24, 2012 at 19:09 history asked Jane Doe CC BY-SA 3.0