Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of pats@acm.org
 does not designate 74.124.218.126 as permitted sender)
Message-ID: <54D91DAE.6070905@acm.org>
Date: Mon, 09 Feb 2015 12:50:54 -0800
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Please review the river-examples project
References: <66437458-B991-4F6F-B5B8-09F6413C37EE@trasuk.com>
 <D6CF18FD-4724-4682-BC9C-0718267ED5CD@asarian-tech.com>
 <33E5CDDA-C2EE-4820-8DD7-87041A2D4227@stratuscom.com>
 <54D902AE.7090405@acm.org> <637ED993-80E1-42D0-AD41-636AC0945438@gmail.com>
In-Reply-To: <637ED993-80E1-42D0-AD41-636AC0945438@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

I think "production" client and test both have value. As far as 
possible, the example should mimic the structure and layout of a 
complete project, but in miniature.

On 2/9/2015 12:37 PM, Dennis Reedy wrote:
>
>> On Feb 9, 2015, at 155PM, Patricia Shanahan <pats@acm.org> wrote:
>>
>> The purpose of a test would be to demonstrate principles of writing tests for River services and clients, rather than to actually test anything.
>>
>> For example, a test of the service could pick different "name" strings, feed them to the service, and compare the returned string to an expected value.
>>
>> How should one test a River client? Replace the service with a stub class implementing its interface???
>
> You could mock out the service, a simple way to do that is Proxy.newProxyInstance(...).
>
> Another way to think about this is to not provide a client at all, because the service's test is actually a client that discovers and invokes methods on the service. The test client then becomes a reference on how to develop a client.
>
> Dennis
>