Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Testdrivendevelopment
- Messages
Search
|
Re: [TDD] What I hate about *Unit frameworks.
Maybe I'm just dense, but: what is it about this that is particular to TDD?
Seems to me that monkey patching without tests is *fuck all* more dangerous than writing a test, making it pass in the simplest way possible, and then improving the design. What am I missing??? On May 1, 2013 8:12 PM, "John Roth" <JohnRoth1@...> wrote: ** [Non-text portions of this message have been removed] |
|
Re: [TDD] What I hate about *Unit frameworks.
John Roth
On 5/1/13 7:12 AM, David Stanek wrote:
Snort. This is a continuing issue for the Python developers as well. John Roth |
|
Re: [TDD] Re: If you could get your colleagues to read just one book on TDD, which would it be?
Dennis,
On 5/1/13 4:29 PM, Dennis Traub wrote: On Wed, May 1, 2013 at 10:24 PM, Keith Ray <keith.ray@...> wrote:You should pair that with The Mikado Method (mikadomethod.org)**I believe that this is one of the most essential books, no matter if you - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ---------------------------------------------------------------------- |
|
Re: [TDD] What I hate about *Unit frameworks.
Keith Ray
The fear of test cases interfering with each other was something thatOne of the "Aha!" Epiphanies of a programmer I was working with, was the realization that a unit test only needs to test a "unit". He had been setting up real-life data, when a little "fake" data would verify the desired behavior. It also makes the code more robust, because side-effects that might not be seen in a system test, can be found by unit tests exercising all the edge-cases for each function or behavior being tested. adrianh@... twitter.com/adrianh [Non-text portions of this message have been removed] |
|
Re: [TDD] Re: If you could get your colleagues to read just one book on TDD, which would it be?
Dennis Traub
On Wed, May 1, 2013 at 10:24 PM, Keith Ray <keith.ray@...> wrote:
**I believe that this is one of the most essential books, no matter if you have to deal with legacy code (everyone has eventually, anyway). |
|
Re: [TDD] Re: If you could get your colleagues to read just one book on TDD, which would it be?
Keith Ray
The following are some books I recommend to developers new to Agile software development.
toggle quoted message
Show quoted text
This book is new, pretty complete, and easy-to-read about adopting agile software development: The Agile Samurai This book covers the same ground as the Agile Samurai book. It's a little more in-depth. Most of it is now free on-line, but you can buy the book from Amazon: The Art of Agile Development. This book is about test-driven development in C: Test Driven Development for Embedded C This is the original TDD book in Java: Test-Driven Development The original book on Refactoring. If you have legacy code, you also need to this book: Working Effectively With Legacy Code. C. Keith Ray On Apr 30, 2013, at 8:46 PM, Bob Graffagnino <rkgraff@...> wrote:
I found goos to be not so much a "how to write tests" book, but more of an illustration of how code can evolve when using TDD. My main criticism with the book is that it is easy to lose the big picture of the application (lots of snippets, few diagrams). |
|
Re: [TDD] What I hate about *Unit frameworks.
Keith Ray
Well, you can run your tests under something like valgrind and it will tellPretty easy to find out. Valgrind gives us the call-stack of the allocation that leaked, and most code is only executed by a few tests. (Google "microtest" to see why (and "Mike Wrote Tests").) Some people make the test-runners keep track of memory usage, and it complains about specific tests. Use code-review and/or pair programming, and sensible coding standards, to make sure other kinds of resources are not leaked. C. Keith Ray
[Non-text portions of this message have been removed] |
|
Re: [TDD] What I hate about *Unit frameworks.
On Thu, May 2, 2013 at 1:58 AM, Adrian Howard <adrianh@...>wrote:
**I guess this could a "per language" thing... In perl, unless you run with -w (which you should), you never even get told about using uninitialized variables, and _every_ variable is initialized to null. In C/C++ the uninitialized stuff sometimes "accidentally" works if there is left over correct values from the previous test lying in memory / on stack etc. -- ------------------------------ This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. ------------------------------ |
|
Re: [TDD] What I hate about *Unit frameworks.
On Wed, May 1, 2013 at 10:27 PM, Angel Java Lopez <ajlopez2000@...>wrote:
Actually... it happened on every one. As soon as you touch the heap, you have changed the system state. If it's a GC'd language this isn't quite so problematic, but you still get other resource leaks. Have you free'd them all? Well, you can run your tests under something like valgrind and it will tell you. Now which test leaked? -- ------------------------------ This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. ------------------------------ |
|
Re: [TDD] What I hate about *Unit frameworks.
Adrian Howard
On 1 May 2013 11:27, Angel Java Lopez <ajlopez2000@...> wrote:
John, usually I don't find the case "this test corrupts that test", and II've seen more of the opposite problem. When previously isolated tests show up a bug when run together - because there was some state that should have been reset that wasn't. A few years back I spent a chunk of time with several organisations moving Perl test suites that were in a one-test-per-process style to a shared xUnit style test (mostly coz I wrote the most popular Perl xUnit framework of the period ;-) The fear of test cases interfering with each other was something that was raised before we did the moves - but it turned out to be largely baseless. I don't have the numbers to hand, but I do remember that we found many more bugs that had been hidden by separate processes than problems due to tests interfering with each other. Cheers, Adrian -- adrianh@... twitter.com/adrianh t. +44 (0)7752 419080 skype adrianjohnhoward pinboard.in/u:adrianh |
|
Re: [TDD] What I hate about *Unit frameworks.
I think it's called "monkey patch" for a reason ...
On May 1, 2013, at 9:12 AM, David Stanek <dstanek@...> wrote: I've seen this in Python tests where developers monkey-patch things and Ron Jeffries www.XProgramming.com There's no word for accountability in Finnish. Accountability is something that is left when responsibility has been subtracted. --Pasi Sahlberg |
|
Re: [TDD] What I hate about *Unit frameworks.
On Wed, May 1, 2013 at 6:27 AM, Angel Java Lopez <ajlopez2000@...>wrote:
I've seen this in Python tests where developers monkey-patch things and forget to set them back or otherwise muck with global state. This has been the result of design issues. -- David blog: twitter: www: |
|
Re: [TDD] What I hate about *Unit frameworks.
Hi everyone!
John, usually I don't find the case "this test corrupts that test", and I wrote thousands of tests. Any example/case? Angel "Java" Lopez @ajlopez gh:ajlopez On Tue, Apr 30, 2013 at 8:30 PM, John Carter <john.carter@...>wrote: ** [Non-text portions of this message have been removed] |
|
Re: [TDD] What I hate about *Unit frameworks.
Donaldson, John
John C,
toggle quoted message
Show quoted text
While I agree with you, I don't see the point of your post. You can produce elegant code on Windows or on Unix. You work with what you've got is all. John D. -----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of John Carter Sent: 01 May 2013 01:30 To: testdrivendevelopment@... Subject: [TDD] What I hate about *Unit frameworks. Most of them invest way too much effort to make up for the deficiencies of the Windows Operating system. The Component in a Computer tasked with managing concurrency, task separation, and ensuring full clean setup and tear down is.... The Operating System. So if you want to be dead, 100% sure that this test doesn't corrupt that test... you use a process. Nope, not try / catch, not exception handling. That's a flaky almost solution. One test === One Process. Each process is an address space that appears.... and vanishes. But, but, but Processes Are HeavyWeight you can't create and run thousands of processes! Oh yes you can. Processes are lightweight under Unix and have been for decades. In fact much of the hype about threads is a result of Microsoft marketing spin to cope with the fact that Windows 3.1 processes were incredibly heavyweight kludges. In fact there are relatively few places where one should use threads when one can use processes. Want to run a thousand tests? Well, how many cores do you have? Let's keep every core 100% busy. One test, one core. But who is going to spin all those processes and mind the result? GNU parallel is a pretty nifty choice. Or maybe it is something the xUnit's should be doing. -- John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@... New Zealand -- ------------------------------ This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. ------------------------------ ------------------------------------ Yahoo! Groups Links |
|
Re: [TDD] Re: If you could get your colleagues to read just one book on TDD, which would it be?
I found goos to be not so much a "how to write tests" book, but more of an illustration of how code can evolve when using TDD. 听My main criticism听with the book is that it is easy to lose the big picture of the application (lots of snippets, few diagrams).
A former co-worker of mine recently uploaded a chapter by chapter implementation of goos听(with Mockito) to git hub that helped me maintain a clear view of the big picture. I also recommend watching Uncle Bob's TDD videos on cleancoders.com after doing the bowling kata. -Bob Graffagnino ________________________________ From: robi.yagel <reuven.yagel@...> To: testdrivendevelopment@... Sent: Tuesday, April 30, 2013 2:43 PM Subject: [TDD] Re: If you could get your colleagues to read just one book on TDD, which would it be? 听 Two books that I can recommend: Osherov, The Art of Unit testing jbrains, Responsible Design for Android - on going work, somewhat builds on GOOS --- In testdrivendevelopment@..., John Carter <john.carter@...> wrote:
|
|
Re: [TDD] What I hate about *Unit frameworks.
Keith Ray
Google's test framework for C++ allows for "death tests" where a separate process is spun up, executed to run a test, and stderr (I think) + result code examined. if the test doesn't cause that process to error out "properly" it is counted as a failure. I suppose there is a time-out involved. (Been a while since I've looked at the code.)
While that gTest framework doesn't come with "sharding (tests spread over threads, processes, or CPUs), that feature could be implemented in your own test-launcher (and something like that might already be used at Google, just not open-sourced. C. Keith Ray On Apr 30, 2013, at 4:30 PM, John Carter <john.carter@...> wrote: Most of them invest way too much effort to make up for the deficiencies of [Non-text portions of this message have been removed] |
|
What I hate about *Unit frameworks.
Most of them invest way too much effort to make up for the deficiencies of
the Windows Operating system. The Component in a Computer tasked with managing concurrency, task separation, and ensuring full clean setup and tear down is.... The Operating System. So if you want to be dead, 100% sure that this test doesn't corrupt that test... you use a process. Nope, not try / catch, not exception handling. That's a flaky almost solution. One test === One Process. Each process is an address space that appears.... and vanishes. But, but, but Processes Are HeavyWeight you can't create and run thousands of processes! Oh yes you can. Processes are lightweight under Unix and have been for decades. In fact much of the hype about threads is a result of Microsoft marketing spin to cope with the fact that Windows 3.1 processes were incredibly heavyweight kludges. In fact there are relatively few places where one should use threads when one can use processes. Want to run a thousand tests? Well, how many cores do you have? Let's keep every core 100% busy. One test, one core. But who is going to spin all those processes and mind the result? GNU parallel is a pretty nifty choice. Or maybe it is something the xUnit's should be doing. -- John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@... New Zealand -- ------------------------------ This email, including any attachments, is only for the intended recipient. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If you are not an intended recipient, you may not use, disseminate, distribute or reproduce such email, any attachments, or any part thereof. If you have received a message in error, please notify the sender immediately and erase all copies of the message and any attachments. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission nor can we guarantee that any email or any attachments are free from computer viruses or other conditions which may damage or interfere with recipient data, hardware or software. The recipient relies upon its own procedures and assumes all risk of use and of opening any attachments. ------------------------------ |
|
Re: If you could get your colleagues to read just one book on TDD, which would it be?
Two books that I can recommend:
toggle quoted message
Show quoted text
Osherov, The Art of Unit testing jbrains, Responsible Design for Android - on going work, somewhat builds on GOOS --- In testdrivendevelopment@..., John Carter <john.carter@...> wrote:
|
|
Re: [TDD] If you could get your colleagues to read just one book on TDD, which would it be?
Hmmm...
On 4/30/13 12:46 AM, Keith Ray wrote: There's about 15 books on TDD (and a few on Refactoring). I wouldI know a number of good books on TDD. I've not read any of them all the way through. I think reading these books and mastering TDD are orthogonal. Mastering requires practicing, not reading. Reading a good book is a shortcut, a boost, but won't make you a master. Lasse Koskela's latest book, Effective Unit Testing, is also good. - George -- ---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ---------------------------------------------------------------------- |
|
Re: [TDD] If you could get your colleagues to read just one book on TDD, which would it be?
TDD By Example +1,
Refactoring +1 GOOS +2 Clean Code +1 Agile Software Development, Principles, Patterns, and Practices On Tue, Apr 30, 2013 at 1:41 AM, Gishu Pillai <gishu.pillai@...>wrote: ** -- 础产谤补鏾蝉, 闯辞蝉耻� |
to navigate to use esc to dismiss