Re: What I hate about *Unit frameworks.

Keith Ray <[email protected]>
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <[email protected]>
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 <[email protected]> wrote:

> 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 : [email protected]
> 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.
> ------------------------------
> 
> [Non-text portions of this message have been removed]
> 
> 


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.