Continuous Integration for KDB

[P_Bukowinski]

tdd has nothing to do with programming language,so there should be nothing to stop you from writing tests and thensome business logic.There should be no problem to define few jobs in hudson to pullchanges from svn/git/etc. and run unit/integration/system tests on*nix slave (no q version dep.).If necessary wrap it around with make/ant/scons at any stage of yourjob schedule.I'd say imagination is the only show stopper ;-).Cheers,Patryksent from droidOn Oct 12, 9:31�am, Ajay wrote:> Hi,>> Has anyone experience of using the modern day's continuous integration> servers for CI and deployment of KDB processes. Like java developers> can use to hudson, cruise.>> What strategy people use to perform test driven development with Q, i> believe that 32-bit KDB version is the only option for running tests> in a CI like environment.>> Ajay

[Attila]

i'm sure somebody from Kx will contact you
but i reckon that the trial license should not be used for anything like th=
is
=A0 Attila

[rohit]

>weather they use free
>version of q for running their tests (which i believe wont work for
>load testing TP and RDB)

Wow

>What are the best practices used for CI in the context of KDB.

So here's the most useful answer I can provide in the context of the above:=
expect meltdowns 🙂


-----Original Message-----
From: personal-kdbplus@googlegroups.com [mailto:personal-kdbplus@googlegrou=
ps.com] On Behalf Of Ajay
Sent: Friday, October 14, 2011 7:29 PM
To: Kdb+ Personal Developers
Subject: [personal kdb+] Re: Continuous Integration for KDB

Being able to program in four different languages, i am fully aware
that tdd could be practiced anywhere.

I think you missed the whole point, i know how to configure jobs in
hudson to run distributed builds on remote machines.

I was more interested in knowing about existing approaches used by
people for configuring CI in their projects, weather they use free
version of q for running their tests (which i believe wont work for
load testing TP and RDB) or they have run their test suit on machines
installed with licensed 64 bit q. What are the best practices used for
CI in the context of KDB.

Ajay

[David_J_Roberts]

Write your tests in Q and commit them to sourcecontrol.�

Have the CI tool synchronize the sourcecontrol tree to your test server when needed.�

Have your CI tool execute the Q binary (licensed) and have your tests log something understandable to the CI tool.

Most CI tools are not much better than a cronned unix script doing the above and emailing any errors, though CI web interfaces are a slight improvement over email.

David

[david_tweed]

Without getting involved in any of the discussions in the thread,there's a technical question related to this I'm interested in. Isthere a way to configure, either by command line or script, things sothat upon an error the Q interpreter doesn't break to the shellprompt? (If I run a script containing an error, the process stops inthe interpreter.) When doing semi-automatic testing of code with amultitude of options I don't really want to do that because:1. Running all the tests might and knowing which ones fail might helpsee the bug quicker than trying to debug the first failure inisolation.2. Even if I do want to debug the failing script, I generally want todo it at a later time in more controlled circumstances.Doing protected evaluation of a full script has the side effect ofmeaning that "top-level code" setting global variables is no longertop-level any more.Is there a known solution to this problem,Thanks, DavidOn Oct 12, 9:31�am, Ajay wrote:> Hi,>> Has anyone experience of using the modern day's continuous integration> servers for CI and deployment of KDB processes. Like java developers> can use to hudson, cruise.>> What strategy people use to perform test driven development with Q, i> believe that 32-bit KDB version is the only option for running tests> in a CI like environment.>> Ajay

[Lukasz_Kedzior]

I use JUnit to run my unit tests, really handy when using Maven forbuild managementFor each q source file1) create JUnit Test Case2) from JUnit Test Case start q process (licensed) and load the q fileunder the test (you can do it with Runtime.exec(command) )3) Execute your test code. You can either call functions under thetest/assert results from JUnit @Test methods or if you have your testswritten in q just load them and executePut all test cases to src/test/java and they will run during maven-test phaseLukaszOn Oct 14, 2:58�pm, Ajay wrote:> Being able to program in four different languages, i am fully aware> that tdd could be practiced anywhere.>> I think you missed the whole point, i know how to configure jobs in> hudson to run distributed builds on remote machines.>> I was more interested in knowing about existing approaches used by> people for configuring CI in their projects, weather they use free> version of q for running their tests (which i believe wont work for> load testing TP and RDB) or they have run their test suit on machines> installed with licensed 64 bit q. What are the best practices used for> CI in the context of KDB.>> Ajay>> On Oct 13, 2:28�pm, "P.Bukowin...@gmail.com" > wrote:>>>>>>>> > tdd has nothing to do with programming language,> > so there should be nothing to stop you from writing tests and then> > some business logic.>> > There should be no problem to define few jobs in hudson to pull> > changes from svn/git/etc. and run unit/integration/system tests on> > *nix slave (no q version dep.).> > If necessary wrap it around with make/ant/scons at any stage of your> > job schedule.> > I'd say imagination is the only show stopper ;-).>> > Cheers,> > Patryk>> > sent from droid>> > On Oct 12, 9:31�am, Ajay wrote:>> > > Hi,>> > > Has anyone experience of using the modern day's continuous integration> > > servers for CI and deployment of KDB processes. Like java developers> > > can use to hudson, cruise.>> > > What strategy people use to perform test driven development with Q, i> > > believe that 32-bit KDB version is the only option for running tests> > > in a CI like environment.>> > > Ajay