Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: "Knudsen, Ken" <Ken.Knudsen@imaginecommunications.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Subject: RE: Unit Test logging with couchDB....
Thread-Topic: Unit Test logging with couchDB....
Thread-Index: Ac9ERFpsPRV2H55ZSdKq0Jq4AEfGiAAPzveA//+/p5U=
Date: Thu, 20 Mar 2014 17:51:39 +0000
Message-ID: 
 <F5FDD679DA03BA4D806BEA7CB6EBCD6F388A0E92@VEREXCH01.harrisbroadcast.com>
References: 
 <F5FDD679DA03BA4D806BEA7CB6EBCD6F388A0AC3@VEREXCH01.harrisbroadcast.com>,<CAHdjipJNRPm-zXMUxgOLOkd63tdqrBY-GZd6+Z+2aNKY49k9Nw@mail.gmail.com>
In-Reply-To: 
 <CAHdjipJNRPm-zXMUxgOLOkd63tdqrBY-GZd6+Z+2aNKY49k9Nw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Yup...So, in whatever unit test framework one is running, the unit tests a=
re running, Assert.Fails and whatever else... but within those tests, say =
you want to write out information about values and other results... or wan=
t to store the end result files themselves in a global store for later ret=
rieval. Many of the frameworks provide a plug-in mechanism so you can writ=
e your own logger plug-in... or the main files that record the overall UT =
runtime information are stored as simple XML formats.. taking that informa=
tion and aggregating it into a central store for use in some fashion by re=
ports etc.

So let's do a typical scenario in our environment... I'll point for it so =
I don't ramble on.

- msbuild environment
- Jenkins as the build CI Server
- Projects are built and install packages made
- Each set of projects can have 1 or more sets of UT binaries generated. T=
hese binaries are all bundled up into their own install package
- On some virtual machine, setup with pre-installed 3'rd party software fo=
r a given product, the Product's main install is done and then the UT inst=
all for that product is done (Using Jenkin jobs to coordinate etc)
- A small internal UTFramework Runner is kicked off and then begins runnin=
g all the given UT's on the system, each recording their information of pa=
ss and fail etc.
- It's that information that we want to capture and record back to a centr=
al location. Now Jenkins can capture the base UT runtime stuff and show th=
e pass fail results...but taking this information, along with anymore deta=
iled logging and storing it in a central DB for use later on is what I'm l=
ooking for. Not overly hard to do...but that's what I'm asking the communi=
ty about: if anyone has done thing's like that or some other best practice=
 scenario's using couchDB in that fashion.

________________________________________
From: Alexander Shorin [kxepal@gmail.com]
Sent: Thursday, March 20, 2014 1:30 PM
To: user@couchdb.apache.org
Subject: Re: Unit Test logging with couchDB....

Hi,

Do you mean under "unit test logging with CouchDB" actually storing
unittest results as CouchDB documents?
--
,,,^..^,,,


On Thu, Mar 20, 2014 at 6:08 PM, Knudsen, Ken
<Ken.Knudsen@imaginecommunications.com> wrote:
> Hi Everyone,
>
>    Obviously there's a thousand plus ways of doing this...Has anyone imp=
lemented or worked with unit testing frameworks but instead of using that =
frameworks built in logging mechanism, broke out that logging part and use=
d couchDB instead? With couchDB there wouldn't be much 'breaking out' give=
n how easy it is to record log information during a UT run with couchDB...=
but I'm interested in anything someone may have to add outside of the obvi=
ous stuff...
>    I watched a talk from the MS guys where they incorporated couchDB int=
o one of their internal unit testing frameworks (Daylight?)...but I can't =
find anything more on it so far as what they built on top of that data cap=
tured, etc.
>
> To keep the discussion as global as possible, the term 'Unit Testing' in=
 this context envelopes all layers, from single component to integration t=
esting.
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service=
.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________