IRC Chat : 2009-05-16 - OpenMRS

00:00:08 <nribeka> before junit test-a-thon
00:00:13 <nribeka> who's joining tomorrow?
00:00:22 <nribeka> everyone in here must join in
00:00:29 <omart13x> not me, sorry
00:00:40 <nribeka> eh why omart13x?
00:01:09 <omart13x> a previous event
00:01:36 <omart13x> but, maybe I can check this channel later
00:01:41 <nribeka> event?
00:01:44 <omart13x> just to know whats going on
00:01:52 <omart13x> a soccer game
00:02:12 <nribeka> ooo ic ic
00:02:51 <omart13x> I never had use JUnit
00:02:53 <omart13x> :S
00:03:15 <nribeka> you can learn :)
00:03:19 <nribeka> i'm still learning too
00:03:20 <nribeka> :D
00:03:26 <nribeka> well, i'm off for now :D
00:03:30 <nribeka> laterz all
00:05:11 <omart13x> cia
00:05:12 <omart13x> o
00:08:30 *** omart13x has quit IRC
00:13:47 *** Keelhaul has joined #openmrs
00:13:47 *** ChanServ sets mode: +v Keelhaul
00:28:04 <Keelhaul> ah curses
00:28:13 <Keelhaul> jmiranda are you there?
00:30:07 <jmiranda> Keelhaul: sort of
00:30:11 <jmiranda> what's up?
00:30:26 <Keelhaul> jmiranda: i'm not sure anymore, can i get back to you later? =P
00:30:30 <Keelhaul> or in general
00:30:44 <Keelhaul> if i mess up in an sqldiff and want to correct it
00:31:11 <Keelhaul> this can be tricky if the table already contains data
00:31:34 <Keelhaul> for some reason one of my tables has fields for BaseOpenmrsMetadata instead of -Data
00:32:21 <jmiranda> this is in a module?
00:32:31 <Keelhaul> yea
00:32:44 <jmiranda> you want to switch it from Metadata to Data?
00:32:49 <Keelhaul> although the sqldiff contains the correct queries
00:33:00 <Keelhaul> for some reason the db i have has a wrong table
00:33:09 <Keelhaul> i remember pasting the query manually for it
00:33:15 <Keelhaul> but not sure from where
00:33:25 <Keelhaul> if the error is not in the repository, it's no biggie
00:33:33 <jmiranda> right
00:33:46 <jmiranda> and even if it was, we goof all the time
00:33:50 <Keelhaul> yea well
00:33:59 <jmiranda> if you can make a correction to the sqldiff to right things
00:34:04 <jmiranda> then that's ok
00:34:18 <Keelhaul> heh
00:34:21 <Keelhaul> thats what i was scared of
00:34:23 <jmiranda> you're the only one using the module right now
00:34:33 <Keelhaul> having all your mistakes documented heh
00:34:39 <Keelhaul> i know
00:34:58 <jmiranda> sorry, that was supposed to be a question
00:35:03 <Keelhaul> yea
00:35:05 <jmiranda> but you answered it anyway
00:35:14 <jmiranda> ok, that shouldn't be a big deal
00:35:21 <jmiranda> if you need help migrating the data though
00:35:23 <jmiranda> let us know
00:35:27 <Keelhaul> the statistics show some downloads but i am sure no implementers use it because it requires 1.5
00:35:35 <jmiranda> i'm sure one of us has run into something like that in the past
00:35:47 <jmiranda> which module
00:35:51 <Keelhaul> inpatientcare
00:35:54 <Keelhaul> well all require 1.5
00:35:57 <Keelhaul> which kinda sucks
00:36:03 <Keelhaul> but i need some things from 1.5
00:36:14 <Keelhaul> the old design might have worked with 1.4
00:36:31 <Keelhaul> it used custom object types for sublocations
00:36:43 <Keelhaul> new design uses the parent-child location hieararchy though
00:36:47 <Keelhaul> which is in 1.5
00:37:28 <Keelhaul> i dont remember why the other modules require 1.5
00:37:43 <Keelhaul> apart from nribeka's hibernate fix which burke and darius seem to hate
00:38:08 <Keelhaul> hm
00:38:26 <jmiranda> hate is a strong word
00:38:28 <Keelhaul> i should start documenting changes to minimum openmrs version requirements any why i made the change
00:38:30 <Keelhaul> heh not hate
00:38:38 <Keelhaul> but uncomfortable with how it works
00:38:44 <jmiranda> they have disdain for it
00:39:01 <Keelhaul> which is sad
00:39:13 <jmiranda> kidding
00:39:29 <jmiranda> what is sad?
00:39:37 <Keelhaul> i seems like it's going to be taken out for 1.5 release
00:40:03 <Keelhaul> which will break my patient system access functions until the data model refactoring in 1.6
00:40:52 <jmiranda> why will they break your code?
00:41:12 <Keelhaul> not necessarily my code
00:41:13 <Keelhaul> you see
00:41:28 <Keelhaul> my design allows for records where user_id == patient_id
00:41:38 <Keelhaul> so the patient can log in and enter data for themselves
00:41:57 <Keelhaul> with records like that in the db, hibernate will throw an exception
00:41:58 <Keelhaul> forgot which
00:42:22 <Keelhaul> nribeka's fix allows for that scenario to work seemingly properly
00:42:35 <Keelhaul> in my own code, i was able to hack around that exception so it still worked
00:42:45 <Keelhaul> but it can break any other code
00:43:08 <Keelhaul> e.g. if i try to open a html form for a patient who is also a user, it will throw an exception
00:44:09 <jmiranda> seems like it might be possible to handle this with a form bean that's not attached to a session
00:44:56 <jmiranda> right?
00:45:00 <Keelhaul> i guess
00:45:09 <Keelhaul> but that could be said for any code
00:45:15 <jmiranda> or is the problem going to occur whenever you pull up the patient record to update it's values
00:45:38 <Keelhaul> not sure
00:45:44 <jmiranda> there are ways around it i assume
00:45:51 <jmiranda> i.e. explicit eviction
00:45:55 <Keelhaul> in htmlformentry, the exception is thrown when you open a form, not when you send it
00:46:15 <jmiranda> but that's binding a patient to the form
00:46:33 <jmiranda> i'm thinking we need to leave the objects in the service layer
00:46:47 <jmiranda> and use form beans (similar to struts)
00:46:50 <Keelhaul> you want a whole new layer for the beans?
00:46:52 <Keelhaul> oh
00:46:55 <jmiranda> that model the form
00:46:59 <jmiranda> rather than the database
00:47:01 <Keelhaul> dont know how struts works
00:47:12 <jmiranda> i always thought that was stupid about our system
00:47:25 <jmiranda> you're not always going to model the UI around the data model
00:47:42 <jmiranda> ben and i argued about this a few years ago
00:48:06 <jmiranda> and i wanted to have different "patient" model objects for different user interfaces
00:48:26 <Keelhaul> hm
00:48:30 <jmiranda> because some interfaces might have a different way of modeling the patient
00:48:42 <Keelhaul> sounds like that would complicate things quite a bit
00:48:49 <jmiranda> not really
00:49:26 <jmiranda> would make the UI design a lot simpler
00:49:40 <Keelhaul> how do you translate it to the API patient then
00:49:42 <jmiranda> you're not trying to fit the UI design to the data model
00:50:22 <jmiranda> either in the controller
00:50:48 <jmiranda> let me try to think of an example
00:51:14 <Keelhaul> sounds to me like a potential source of many errors to make =(
00:51:49 <jmiranda> what types of errors
00:52:12 <Keelhaul> wrong mapping to the data model object etc
00:52:26 <Keelhaul> if it has to be done in the controller code
01:06:00 <jmiranda> maybe, i'll think of a good example and get back to you
01:06:07 <jmiranda> need to go get some dinner and a movie
01:06:20 <jmiranda> so i'll see you later
01:11:52 <Keelhaul> ok hf
01:26:54 *** bodobacs has quit IRC
01:31:59 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7800]: reporting module: Support getting CohortDefinition by UUID, check in … <http://dev.openmrs.org/changeset/7800> || OpenMRS Changesets: Changeset [7799]: reporting: Fixed dataset related unit tests. * Modified all unit tests … <http://dev.openmrs.org/changeset/7799> || OpenMRS Tickets: Ticket #1492 (task closed): Missing Service methods to get SerializedObject by UUID <http://dev.openmrs.org/ticket/1492#comment:1> || OpenMRS Changesets: Changeset [7798]: ticket #1492. Adding methods to get SerializedObject by UUID in … <http://dev.openmrs.org/changeset/7798> || OpenMRS Tickets: Ticket #1492 (task created): Missing Service methods to get SerializedObject by UUID <http://dev.openmrs.org/ticket/1492>
01:51:36 *** Echidna has joined #openmrs
01:54:45 *** Echidna_ has quit IRC
02:03:59 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7802]: Enable SerializedObjectDAO to retrieve objects by either partial or exact … <http://dev.openmrs.org/changeset/7802> || OpenMRS Changesets: Changeset [7801]: ncd: partial progress on hibernate mapping object renaming and javadoc … <http://dev.openmrs.org/changeset/7801>
02:36:01 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7803]: redesigned the user-location mapping menu, filtered beds out of the … <http://dev.openmrs.org/changeset/7803>
02:52:44 *** jmiranda has quit IRC
02:52:52 *** jmiranda has joined #openmrs
02:52:52 *** irc.freenode.net sets mode: +o jmiranda
02:58:46 *** atomicturtle1 has joined #openmrs
02:58:46 *** atomicturtle has quit IRC
03:08:05 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7805]: serialization: updata the class name of MyCollectionShortConverter.class <http://dev.openmrs.org/changeset/7805> || OpenMRS Changesets: Changeset [7804]: reporting module: Enable CohortDefinitionService to retrieve … <http://dev.openmrs.org/changeset/7804>
04:12:05 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7806]: reporting module: Implement DataSetDefinition persistence <http://dev.openmrs.org/changeset/7806>
04:25:20 <nribeka> jmiranda, can we start early on the test-a-thon
04:25:23 <nribeka> just kidding :D
04:25:30 <nribeka> wanna watch angels and demons
04:25:51 <Keelhaul> prison break season finale almost done downloading
04:34:43 <jmiranda> nribeka: just got back from a really good film (sin nombre)
04:35:05 <jmiranda> am about to put together the instructions and "howto's" for tomorrow
04:35:32 <jmiranda> but if you want to start early, be my guest :)
04:35:52 <nribeka> hahahahaha
04:35:57 <nribeka> just kiddin jmiranda
04:36:02 <nribeka> i think i need some sleep now
04:36:06 <nribeka> sleep deprivation
04:36:25 <jmiranda> i know
04:36:30 <jmiranda> good night
04:36:37 <jmiranda> how was your trip?
04:36:43 <nribeka> it was fun
04:36:44 <nribeka> haha
04:36:54 <nribeka> that was my second actually
04:37:00 <nribeka> i wanna see madison too
04:37:07 <jmiranda> anytime
04:37:08 <nribeka> so i hope i will have the chance :)
04:37:15 <nribeka> to meet you
04:38:39 <jmiranda> yeah, that would be cool
04:39:16 <Keelhaul> where do you guys live
04:39:58 <nribeka> pittsburgh, pa
04:40:10 <jmiranda> wisconsin
04:44:07 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7810]: reporting module: JoinDataSetDefinitionEvaluator test <http://dev.openmrs.org/changeset/7810> || OpenMRS Changesets: Changeset [7809]: reporting module: Add DataSetWrappingDataSetDefinition and … <http://dev.openmrs.org/changeset/7809> || OpenMRS Changesets: Changeset [7808]: reporting module: Add DataSetWrappingDataSetDefinition and … <http://dev.openmrs.org/changeset/7808> || OpenMRS Changesets: Changeset [7807]: reporting module: Add a SimpleDataSet implementation backed by an … <http://dev.openmrs.org/changeset/7807>
04:52:43 *** jmiranda1 has joined #openmrs
04:53:52 *** jmiranda has quit IRC
05:16:07 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7811]: reporting: Ignore dist directory. <http://dev.openmrs.org/changeset/7811>
05:51:04 *** Keelhaul has quit IRC
05:58:54 *** atomicturtle has joined #openmrs
05:58:54 *** atomicturtle1 has quit IRC
07:02:41 *** luzhuangwei has joined #openmrs
07:24:14 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7812]: groovy module: We now have a hot key to execute the scripts. <http://dev.openmrs.org/changeset/7812>
08:28:17 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Tickets: Ticket #1442 (enhancement closed): Groovy Module: Need new shortcut key for running script <http://dev.openmrs.org/ticket/1442#comment:3>
08:57:44 *** atomicturtle1 has joined #openmrs
08:57:44 *** atomicturtle has quit IRC
09:32:20 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7815]: groovy module: per burke's private email. <http://dev.openmrs.org/changeset/7815> || OpenMRS Changesets: Changeset [7814]: groovy module: need to commit this. <http://dev.openmrs.org/changeset/7814> || OpenMRS Changesets: Changeset [7813]: groovy module: hotkey is now Ctrl+R, Alt+R, Shift+Ctrl+R and Shift+Alt+R; … <http://dev.openmrs.org/changeset/7813>
09:33:59 *** kane77 has joined #openmrs
10:25:00 *** lzw_ has joined #openmrs
10:43:15 *** luzhuangwei has quit IRC
11:38:16 *** lzw_ has quit IRC
11:39:18 *** luzhuangwei has joined #openmrs
11:58:36 *** atomicturtle has joined #openmrs
11:58:36 *** atomicturtle1 has quit IRC
12:00:22 *** nimanthab has joined #openmrs
13:04:37 *** jmiranda1 has quit IRC
13:19:51 *** jmiranda has joined #openmrs
13:19:51 *** ChanServ sets mode: +o jmiranda
13:24:33 *** Keelhaul has joined #openmrs
13:24:33 *** ChanServ sets mode: +v Keelhaul
14:58:13 *** atomicturtle1 has joined #openmrs
14:58:13 *** atomicturtle has quit IRC
15:20:07 *** vanmh has quit IRC
15:29:11 *** jmiranda has quit IRC
15:46:59 *** jmiranda has joined #openmrs
15:46:59 *** ChanServ sets mode: +o jmiranda
15:56:58 *** Glen_ has joined #openmrs
15:57:27 <Glen_> Hi all
16:00:33 <jmiranda> hey Glen_
16:01:59 *** Glen_ has quit IRC
16:02:11 *** Glen_ has joined #openmrs
16:11:39 <jmiranda> Glen_: do you have any questions?
16:12:07 <Glen_> just getting the testathon branch checked out right now.
16:12:27 <Glen_> jmiranda: I'll have questions in a couple of minutes
16:16:23 *** nribeka1 has joined #openmrs
16:17:02 <Glen_> jmiranda: there are 4 of us?
16:17:18 <jmiranda> as of right now, there are two of us
16:17:21 <jmiranda> me and you :)
16:17:37 <jmiranda> but nribeka and ben will be joining at some point
16:18:19 <jmiranda> and whoever else hadn't signed up but wants to get in on the action
16:24:38 *** atomicturtle1 has left #openmrs
16:29:45 <nribeka1> jmiranda, how to begin with the test-a-thon?
16:29:54 <Glen_> jmiranda: can I get edit permissions on the minutes? mcglen@gmail.com
16:29:57 <nribeka1> checking out now ...
16:30:27 <jmiranda> nribeka1: http://openmrs.org/wiki/Technical_Workshop_05/16-05/17/2009_Agenda#Getting_Started
16:30:32 <OpenMRSBot> <http://ln-s.net/3CAw> (at openmrs.org)
16:30:45 <jmiranda> Glen_: yeah, i'll make it world writable
16:34:12 *** nribeka has quit IRC
16:34:21 <jmiranda> Glen_: turns out you cannot make a document world writable
16:34:26 <jmiranda> probably for good reasons
16:34:40 <jmiranda> i'll add you using your gmail account
16:35:04 <jmiranda> if anyone else wants to be able to write to the document, please send me an email asking for permission
16:36:17 <Glen_> jmiranda: thanks
16:43:26 <Glen_> jmiranda: suggest a class for me. I'm having trouble telling which classes have poor coverage and which are just plain small.
16:44:08 <jmiranda> sure
16:44:34 <jmiranda> OrderService
16:44:48 <Glen_> thanks
16:45:04 <jmiranda> Glen_: actually ... start with UserService
16:45:15 <Glen_> jmiranda: alright
16:45:22 <jmiranda> that might be better since it's more general and behaviors will be easy to write for that one
16:46:50 <jmiranda> Glen_: oops ... i think our google doc changes just collided
16:46:58 <jmiranda> i'll let you add your class
16:50:56 <nribeka1> how about for me jmiranda?
16:50:57 <nribeka1> :D
16:51:00 <nribeka1> any suggestions?
16:51:14 <Keelhaul> "Every programmer knows they should write tests for their code. Few do. The universal response to "Why not?" is "I'm in too much of a hurry." This quickly becomes a vicious cycle- the more pressure you feel, the fewer tests you write. The fewer tests you write, the less productive you are and the less stable your code becomes. The less productive and accurate you are, the more pressure you feel. " --Socrates
16:51:15 <Keelhaul> rofl
16:51:28 <jmiranda> nribeka1: what have you had the most experience with?
16:51:47 <jmiranda> Keelhaul: wasn't it?
16:51:55 <Keelhaul> wasnt what
16:51:59 <nribeka1> hmm ... patient related, user, person
16:52:01 <jmiranda> wasn't it Socrates
16:52:07 <jmiranda> who said that
16:52:21 <jmiranda> nribeka1: PatientService
16:52:25 <Keelhaul> did they have unit tests back then?
16:52:41 <jmiranda> so nribeka1, Glen_: just write some @should behaviors for now
16:53:02 <nribeka1> socrates? like in the old time socrates?
16:53:06 <jmiranda> add those to the javadoc and commit them as you go or when you feel confident
16:53:08 <nribeka1> they have programming?
16:53:16 <jmiranda> Keelhaul: seriously?
16:53:20 <jmiranda> of course they did
16:53:35 <jmiranda> i mean, they didn't have junit tests
16:54:16 <jmiranda> i wonder if i could get in trouble for mis-attribution of a quote ... is that a crime?
16:54:54 <nribeka1> http://ci.openmrs.org/clover/index.html
16:55:48 <jmiranda> we need about 400 @should's to get to our goal
16:56:29 <jmiranda> so once we finish adding around 400 - 500 @should (for as many service interfaces and API classes as possible)
16:56:40 <jmiranda> then we can move on to implementing the test cases
16:58:18 <Glen_> where is the UserService implementation class?
16:58:35 <Glen_> nevermind
16:58:37 <Glen_> found it
17:05:21 <nribeka1> i'm still noob so please point out if i put the an inappropriate @should
17:07:01 <jmiranda> sure
17:07:08 <jmiranda> yeah, i'm still learning too
17:07:22 <jmiranda> do a "File" search on @should over *.java
17:07:28 <jmiranda> to get some examples
17:07:44 <jmiranda> the most effective way of writing behaviors is to look at the method in the service layer
17:08:01 <jmiranda> and write what you *think* it should do
17:08:18 <jmiranda> rather than writing what it does do
17:12:16 <Keelhaul> will the branch be merged into trunk afterwards?
17:29:24 <jmiranda> Keelhaul: yes
17:29:41 <jmiranda> not immediately, but once the tests are all complete
17:30:02 <jmiranda> we'll probably work on this over the week to make sure everything looks ok (maybe a code review on tuesday)
17:30:48 <Keelhaul> ic
17:30:51 <Keelhaul> so hm
17:31:02 <Keelhaul> i might tackle the rest of the validators tonight
17:31:09 <Keelhaul> theres a ticket for it still
17:31:26 <Keelhaul> i'm not sure whether to do it in the branch or a ticket for trunk
17:31:58 <jmiranda> which branch?
17:32:08 <jmiranda> testathon
17:32:21 <jmiranda> oh, you just need to add the tests for the validators?
17:32:30 <jmiranda> you can certainly add it to the testathon
17:32:43 *** nimanthab has quit IRC
17:32:49 <Keelhaul> yea
17:32:52 <jmiranda> but either way is fine
17:34:31 <Keelhaul> what do we do with the changes we make to the branch
17:34:39 <Keelhaul> just go and commit?
17:35:41 <jmiranda> sure
17:36:02 <jmiranda> just don't make any changes to the core code
17:36:10 <jmiranda> (other than to add @should behaviors)
17:36:11 <Keelhaul> hehe
17:36:19 <Keelhaul> not everyone can commit though
17:36:27 <jmiranda> to testathon?
17:36:37 <jmiranda> i hope they can
17:36:43 <jmiranda> will talk to ben about that
17:37:21 <Keelhaul> well
17:37:28 <jmiranda> nribeka1 and Glen_: i am writing up some example @should statements in the Google Doc
17:37:45 <jmiranda> feel free to use any of those (or add your own)
17:41:48 <jmiranda> are you guys finding it [easy, difficult] to write the @should's?
17:42:20 <nribeka1> hard ...
17:42:21 <nribeka1> haha
17:42:52 <Keelhaul> that depends
17:43:15 <Keelhaul> if you already know what the method does and just phrase it in should
17:43:35 <Keelhaul> but if you want to cover things that it should do but arent implemented yet, it gets a bit harder
17:43:44 <Keelhaul> you ahve to be very familiar with the design
17:43:52 *** ChanServ sets mode: +v nribeka1
17:43:58 *** nribeka1 is now known as nribeka
17:45:08 <jmiranda> Keelhaul: exactly
17:45:21 <jmiranda> or with how you expect/want it to behave
17:45:24 <Keelhaul> thats why validators are pretty easy to cover
17:45:42 <Keelhaul> their expected behavior is limited to the fields
17:45:43 <jmiranda> which is why we probably should have users/implementers involved in the process
17:46:35 <Glen_> jmiranda: I'm just working my way down the class. Most of the methods are one-line calls or deprecated. I don't add @shoulds for them.
17:46:51 <jmiranda> cool
17:47:58 <Keelhaul> Glen_: trivial methods shouldnt be covered, i think
17:48:03 <Keelhaul> especially getters/setters
17:48:29 <jmiranda> Keelhaul: yeah, that's debatable
17:48:32 <jmiranda> i agree
17:48:49 <jmiranda> but purists might say that every method should be covered
17:49:16 <Keelhaul> this.id = id;
17:49:21 <Keelhaul> @should set id correctly
17:49:21 <Keelhaul> lol
17:49:45 <jmiranda> yeah
17:49:47 <jmiranda> pointless
17:49:57 <Glen_> too simple to break (http://junit.sourceforge.net/doc/faq/faq.htm#best)
17:49:59 <OpenMRSBot> <http://ln-s.net/3CBx> (at junit.sourceforge.net)
17:51:14 <jmiranda> i think if a getter or setter has a conditional statement
17:51:44 <jmiranda> then it might need to be tested, but otherwise it's pointless (as the best practice points out)
17:51:52 <Keelhaul> if hibernate uses it, i heard it's advised against putting any logic into getters and setters
17:52:26 <jmiranda> yeah ... the only time i can imagine it being used is for getting at singletons
17:52:32 <jmiranda> getInstance() methods
17:54:37 <jmiranda> we do have a few getSomething() methods that iterate over a list of all objects
17:54:47 <jmiranda> and return only unretired/unvoided
17:57:44 <Keelhaul> i'm reading that introduction to BDD you linked
17:57:54 <Keelhaul> public class AccountIsInCredit implements Given {
17:57:58 <Keelhaul> thats pretty fine grained lol
17:58:47 *** atomicturtle has joined #openmrs
18:00:13 *** atomicturtle has left #openmrs
18:01:18 *** luzhuangwei has quit IRC
18:05:26 <Glen_> to me ... BDD seems like "happy path testing"
18:14:07 <jmiranda> Glen_: why do you say that?
18:14:14 <jmiranda> we want to cover all test cases
18:18:57 <Glen_> jmiranda: well the emphasis is on the "should". I didn't see much about "shouldn't" in the BDD intro
18:19:30 <jmiranda> Glen_: :) well, we definitely want to cover the should not's
18:20:10 <jmiranda> check the EncounterService for some examples of "@should not" behaviors
18:21:44 <Keelhaul> jmiranda
18:21:54 <Keelhaul> for ValidationUtils.rejectIfEmptyOrWhitespace(errors, "name", "error.name");
18:22:04 <Keelhaul> i have @should fail validation if name is null or empty
18:22:10 <Keelhaul> or should it be 2 tests
18:22:37 <jmiranda> what happens? does it throw an exception?
18:23:19 <jmiranda> i think there should be two there
18:23:33 <Keelhaul> no, just a design question
18:23:33 <jmiranda> one for null, one for empty string
18:23:37 <Keelhaul> i've used one so far
18:23:43 <Keelhaul> i guess i have to redo my older tests then
18:24:05 <jmiranda> well, you can specify two asserts in the same test
18:24:15 <Keelhaul> yea
18:24:19 <jmiranda> which is fine
18:24:23 <jmiranda> especially for this
18:24:29 <Keelhaul> but i also have to add a line that changes the value in between
18:24:33 <jmiranda> since ValidationUtils is not an openmrs class
18:24:41 <Keelhaul> true
18:24:41 <jmiranda> yeah, exactly
18:25:02 <jmiranda> for stuff like that (changing values between asserts, you @should have two tests)
18:25:20 <jmiranda> but it's debatable since this isn't our code and we just want to have a sanity check that it works as we expect
18:25:31 <Keelhaul> well
18:25:38 <Keelhaul> i think it's ok to have more than one assert
18:27:32 <Keelhaul> ConceptClass cc = (ConceptClass) obj;
18:27:32 <Keelhaul> if (cc == null) {
18:27:32 <Keelhaul> errors.rejectValue("conceptClass", "error.general");
18:27:36 <Keelhaul> this cant be tested
18:27:43 <Keelhaul> i tried
18:31:03 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Tickets: Ticket #1428 (enhancement reopened): Groovy Module: Print output as it happens <http://dev.openmrs.org/ticket/1428#comment:6> || OpenMRS Changesets: Changeset [7817]: groovymodule: Alt+R to run, running feedback, limits on resizing code … <http://dev.openmrs.org/changeset/7817> || OpenMRS Changesets: Changeset [7816]: dataintegrity: completed junit test class and successfully implemented a … <http://dev.openmrs.org/changeset/7816>
18:33:21 <Glen_> jmiranda: question for you in the minutes (when you get a chance)
18:33:31 <jmiranda> what's up
18:33:35 <jmiranda> oh
18:33:38 <jmiranda> let me check
18:33:55 <Keelhaul> jmiranda: why is there no validator for Encounter, the checks are done in processFormSubmission instead
18:34:36 <jmiranda> Glen_: good question
18:34:53 <jmiranda> i think that those @should's should be on the dao
18:35:20 <jmiranda> but i don't think the dao should have much logic in it
18:35:31 <jmiranda> it would be better to pull the logic up to the service layer
18:35:41 <jmiranda> and keep the @should's where they are
18:36:04 <jmiranda> but yes, for one-liners, the general approach is to put @should's where the logic is
18:36:21 <jmiranda> ignoring the one liner delegation method
18:36:56 <jmiranda> Keelhaul: it's possible that the Encounter form was added early, before we adopted the Validator pattern
18:37:14 <Glen_> jmiranda: I'm reluctant to refactor that today ... given I'm still not that familiar with the core codebase
18:37:52 <jmiranda> Glen_: yeah
18:37:55 <jmiranda> no refactoring today
18:38:19 <nribeka> jmiranda, question
18:40:01 <Glen_> jmiranda: the opposite to my argument is that since we're adding @shoulds to interfaces ... they should test everything. The interface is ignorant to any underlying logic. In theory the high-level tests would be the only way to test a new / different implementation the interface.
18:40:24 <jmiranda> nribeka: hit me
18:41:01 <jmiranda> Glen_: yeah, unit tests test the individual classes
18:41:12 <jmiranda> integration tests will test what you're talking about
18:41:42 <jmiranda> so, in my opinion, it's fine to have tests that are duplicated on the two levels
18:42:08 <Glen_> alright, thanks
18:42:20 <Glen_> I'll continue as I've been doing it
18:42:36 <Keelhaul> duplicated on which levels
18:42:53 <jmiranda> Keelhaul: service and DAO
18:43:23 <jmiranda> if you have a service method like saveSomething() that just calls the dao.saveSomething() method
18:43:32 <jmiranda> do you have the same tests on both objects?
18:43:38 <Keelhaul> no
18:43:42 <Keelhaul> i just test in the api layer
18:43:44 <jmiranda> why not?
18:43:53 <Keelhaul> the dao just makes a call to hibernate
18:44:49 <Glen_> I'd test the method that has logic ... if neither of them have logic I wouldn't test either.
18:44:54 <jmiranda> the test on the service layer would be considered an integration test, while the test on the DAO would be considered the unit test because that's where the logic lives
18:45:16 <jmiranda> the naming is kind of irrelevant, but i'm guessing it's ok to have the test cases on both levels
18:45:25 <nribeka> jmiranda, something like this: http://pastebin.com/m6e8ff907
18:45:29 <Keelhaul> Glen_: you'd test the Impl class methods?
18:45:29 <jmiranda> since there's a distinction between the two types of tests
18:45:48 <nribeka> could i add test to see if it's going to throw exc when reason is null or ""
18:46:10 <Keelhaul> jmiranda: there's hardly any logic in the dao layer
18:46:15 <jmiranda> Keelhaul: true
18:46:16 <nribeka> and test whether it is retiring the identifier by checking the retired property of the patient identifier type?
18:46:17 <Keelhaul> just the adding of criteria
18:46:22 <Keelhaul> in more complex getters
18:46:48 <Glen_> Keelhaul: that's a question I have. should unit tests be on the interface or the implementation class?
18:47:03 <jmiranda> nribeka: (and Glen_ / Keelhaul) this is one of the cases that i wanted someone to bring up
18:47:19 <Keelhaul> Glen_: good question
18:47:22 <Keelhaul> not sure
18:47:43 <nribeka> i put the should in the interface
18:47:47 <jmiranda> first of all, we definitely want to write the test cases from the perspective of the interface
18:48:00 <Keelhaul> nribeka: i think that test should be in the validator
18:48:02 <jmiranda> yeah, the @shoulds should go in the interface
18:48:05 <jmiranda> but the question is
18:48:19 <jmiranda> do you determine expected behavior from the interface or from the impl class
18:48:22 <Keelhaul> nribeka: check LocationValidator
18:48:31 <jmiranda> the problem with creating @shoulds based on the impl
18:48:44 <Keelhaul> well
18:48:44 <Keelhaul> yea
18:48:49 <jmiranda> is that you are possibly perpetuating a bug or incorrect expected behavior
18:48:53 <Keelhaul> an interface couldhave multiple implementations
18:49:00 <Keelhaul> with different behavior
18:49:02 <jmiranda> (or that)
18:49:10 <jmiranda> well, they should have the same behavior
18:49:18 <Keelhaul> the basica behavior, yes
18:49:30 <jmiranda> unless we're talking about the difference between a mail message service and sms message service
18:49:33 <Keelhaul> but if you go into detail, different implementations will certainly differ in some ways
18:49:53 <jmiranda> but yeah, the expected behaviors should be narrowed down to common @shoulds
18:50:23 <Keelhaul> one implementation might reject some values while another wouldnt
18:50:35 <jmiranda> @should send message with expected text
18:50:42 <jmiranda> rather than
18:50:50 <jmiranda> @should send email message with expected text
18:51:10 <jmiranda> but this is a tough one to answer i guess
18:51:28 <jmiranda> because the implementation also depends on the underlying resources
18:51:35 <jmiranda> a mail service, an SMS gateway
18:51:48 <jmiranda> these are integration tests though
18:51:52 <jmiranda> and not unit tests
18:52:07 <nribeka> so, we need to be able to figure out what is the method expected to do without looking at the implementation jmiranda?
18:52:08 <jmiranda> so i guess the answer would be "both"
18:52:29 <jmiranda> the interface should have all expected behaviors for any implementation
18:52:41 <Glen_> nribeka: it's a catch22
18:52:54 <Keelhaul> jmiranda: that would mean both the interface and the implementation should have tests
18:52:56 <Keelhaul> which sucks =/
18:53:08 <jmiranda> and the impl class might have integration test cases
18:53:12 <jmiranda> Keelhaul: yeah it does
18:53:24 <jmiranda> and for now, i want to handle just unit tests on the interface
18:53:29 <Glen_> Keelhaul: tests with different purposes
18:53:30 <jmiranda> what should it always do
18:53:34 <Keelhaul> jmiranda: why do services implement interfaces anyway?
18:53:45 <jmiranda> nribeka: for the first pass, yes
18:54:01 <jmiranda> but we can go back and take a look at the implementation to see if we missed something
18:54:51 <jmiranda> and when you start to see some complicated logic, try to create expected behaviors from what you think it's trying to do
18:55:26 <jmiranda> rather than seeing
18:55:46 <jmiranda> if (object == null) throw new APIException()
18:56:00 <jmiranda> and writing
18:56:12 <jmiranda> @should fail when object is null
18:56:22 <jmiranda> because maybe it's supposed to fail when object is not null
18:56:34 <jmiranda> (stupid example, but do you get the point?)
18:56:48 <nribeka> ic ic
18:56:49 <jmiranda> just don't think that because it's in the code, it's correct
18:57:16 <Keelhaul> jmiranda: i think exceptions are a special case
18:57:16 <jmiranda> try to think of expected behavior
18:57:21 <jmiranda> and then try to break the code
18:57:33 <jmiranda> Keelhaul: how so?
18:57:44 <jmiranda> should they be written as @should throw exception when ...
18:58:38 <Keelhaul> yea
18:58:45 <jmiranda> yeah, i kind of agree
18:58:49 <Keelhaul> but theres a special annotation for expected exceptions
18:58:51 <Keelhaul> forgot how it goes
18:58:52 <jmiranda> i was having trouble with that a few minutes ago
18:59:15 <jmiranda> trying to figure out whether the test cases should be general (i.e. "fail") or specific ("throws ...")
18:59:29 <Keelhaul> @Test(expected = APIException.class)
18:59:34 <jmiranda> ahh
18:59:53 <jmiranda> but is there a way to say expected on certain conditions?
19:00:44 <jmiranda> nm, you write the test case around that condition
19:01:02 <jmiranda> this just keeps you from having to write
19:01:05 <Keelhaul> you create the condition and if the exception is throw, the test passes
19:01:06 <Keelhaul> no asserts
19:01:30 <jmiranda> try{ ... } catch (APIException e) { Assert.success(); }
19:01:38 <jmiranda> yeah
19:03:12 <jmiranda> has anyone been able to get the test generator to work?
19:03:55 <Keelhaul> it works for me sometimes
19:03:57 <Keelhaul> heh
19:04:03 <jmiranda> you guys can start committing whenever you'd like
19:04:18 <Keelhaul> jmiranda: i cant find a way to force a passed assert
19:04:27 <Keelhaul> there'S no Assert.success()
19:04:32 <jmiranda> and we can continue doing @should's all night if we wanted, but i want to give you guys a chance to write some test cases as well
19:04:37 <jmiranda> Keelhaul: i know
19:04:52 <jmiranda> i forgot what the method was
19:05:07 <jmiranda> Assert.assertTrue(true);
19:05:11 <jmiranda> something like that
19:05:17 <nribeka> another question jmiranda about the interface thing :D
19:05:26 <nribeka> i hope i didn't miss a thing in the irc
19:05:54 <Keelhaul> jmiranda: will that work though
19:06:09 <jmiranda> Keelhaul: i think it should
19:06:09 <Keelhaul> you make an assert check that always passes if the exception is thrown
19:06:10 <nribeka> if we write the @should from interface pov, then (almost) all the method will have @should?
19:06:19 <Keelhaul> if its nto thrown, there are no checks and the test still passes
19:06:28 <jmiranda> Assert.fail() after the catch
19:06:34 <Keelhaul> maybe you should set an initially false variable to true within the catch block
19:06:42 <Keelhaul> hm
19:06:46 <Keelhaul> yea
19:06:50 <jmiranda> Keelhaul: yeah, that would work too
19:06:58 <Keelhaul> will it definitely stop after the exception?
19:07:01 <Keelhaul> if it is thrown
19:07:07 <jmiranda> nribeka: yeah
19:07:25 <jmiranda> it's better to have @should's than not to have them (in my opinion)
19:07:26 <nribeka> ok ok jmiranda
19:07:36 <jmiranda> if it's a setDao() you can ignore
19:07:41 <nribeka> yeah
19:07:45 <jmiranda> if it's an @deprecated, you can ignore it
19:07:49 <nribeka> it's too simple to break
19:08:12 <jmiranda> that we'll have to determine when we look at the impl
19:08:20 <nribeka> this is cool :D
19:08:22 <jmiranda> i wasn't saying that we can't look at the impl
19:08:32 <nribeka> i can learn junit-ing :D
19:08:33 <jmiranda> we definitely need to
19:08:44 <jmiranda> i just don't want the implementation to cloud our judgment
19:09:21 <jmiranda> eventually, when we go to the impl, it will be important to capture all of the test cases that are there
19:09:32 <jmiranda> all condiitions, all exceptions, etc
19:10:07 <jmiranda> but we may need to have another test-a-thon or @should-a-thon just to make sure that all the @shoulds describe actual expected behavior
19:10:10 <jmiranda> and not bugs
19:15:09 <Keelhaul> jmiranda
19:15:10 <Keelhaul> http://rafb.net/p/D8HY7m59.html
19:15:12 <Keelhaul> what does this mean
19:15:17 <Keelhaul> do i have that library in my module now
19:15:41 <jmiranda> you can reference that from trunk
19:15:54 <jmiranda> you probably don't have it in your module
19:24:53 *** bwolfe has joined #openmrs
19:24:53 *** ChanServ sets mode: +o bwolfe
19:28:45 *** bwolfe has quit IRC
19:28:56 *** bwolfe has joined #openmrs
19:28:56 *** ChanServ sets mode: +o bwolfe
19:31:07 <bwolfe> haven't seen any testathon commits yet...
19:35:17 <jmiranda> soon
19:35:52 <Keelhaul> =)
19:35:54 <Keelhaul> hi bwolfe
19:37:05 <jmiranda> bwolfe: do we need to open up permissions on the testathon branch?
19:39:15 <Keelhaul> does anyone know when Collection<User> providers was added to getEncounter()?
19:41:30 <jmiranda> Keelhaul: no idea
19:41:31 <jmiranda> why?
19:41:35 <bwolfe> jmiranda: permissions are open to anyone that has committed
19:41:48 <jmiranda> ok
19:41:57 <jmiranda> thanks
19:41:58 <bwolfe> jmiranda: we might need to add a few names to the svn/svn-access list on dev.openmrs.org though
19:42:03 <bwolfe> hey Keelhaul
19:42:30 <jmiranda> bwolfe: looks like Keelhaul, Glen_, nribeka are the only ones that might commit
19:43:05 <jmiranda> no one else (r0bby basic` Echidna jacobb kane77 meonkeys rryan) is around :)
19:43:12 <bwolfe> Keelhaul and nribeka have commit rights. can't remember if Glen_ has committed anything to the repo before though
19:43:29 <jmiranda> (that was a passive aggressive attempt at waking everyone else up)
19:43:36 <Keelhaul> jmiranda: Echidna is my server
19:43:41 <bwolfe> we could ping omar and jao, I think they said they might participate
19:43:52 <bwolfe> tell Echidna to get to work then!
19:44:12 <jmiranda> Echidna: what's your deal?
19:44:16 <Keelhaul> it is working
19:44:18 <bwolfe> ok, I need to run. I'll be back in a few hours
19:44:20 <Keelhaul> leeching tv shows for me =P
19:44:31 <jmiranda> bwolfe: later
19:44:35 <Keelhaul> bye
19:48:15 <Glen_> I've never committed before. Do I need a trac account?
19:49:33 <jmiranda> Glen_: yeah
19:49:50 <jmiranda> you can also just create a patch
19:49:55 <jmiranda> and i'll commit it for you
19:50:10 <Glen_> ok. thanks.
19:50:10 <jmiranda> but let's get you an account
19:50:33 <jmiranda> so you can at least upload the patch to a ticket
19:50:47 <jmiranda> http://dev.openmrs.org/register
19:52:03 <jmiranda> i now have a working Generate Test Cases plugin
19:54:31 <Keelhaul> jmiranda: can you help me with this: http://rafb.net/p/OBhh9B41.html
19:56:03 <nribeka> that i think is jsp-api.jar Keelhaul
19:57:35 <Keelhaul> oh
19:58:10 <Keelhaul> nribeka: cant find it anywhere
19:59:35 <nribeka> testathon has one
19:59:41 <nribeka> trunk has it
20:00:02 <Keelhaul> yea i see now
20:00:17 <Keelhaul> i wonder why i never needed it before
20:02:18 <jmiranda> Keelhaul: i think that's been around for awhile
20:02:35 <jmiranda> TagSupport is used extended/implemented by any tag library
20:02:43 <jmiranda> it might have been in the servlet jar before
20:03:50 <Keelhaul> weird
20:03:56 <Keelhaul> now i have to import all that stuff manually
20:03:58 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Tickets: Ticket #1494 (enhancement created): Ability to stop long-running Groovy scripts <http://dev.openmrs.org/ticket/1494> || OpenMRS Tickets: Ticket #1493 (enhancement created): Allow Groovy scripts to report on progress <http://dev.openmrs.org/ticket/1493>
20:04:02 <Keelhaul> now it wants jstl
20:05:16 <Keelhaul> the singer from malta is a real blimp
20:05:35 <jmiranda> if you guys need/want to upload your testathon patches somewhere
20:05:39 <jmiranda> there's a new ticket
20:05:39 <jmiranda> http://dev.openmrs.org/ticket/1495
20:05:44 <Keelhaul> oops wrong channel =o
20:05:53 <jmiranda> !ticket 1495
20:05:53 <OpenMRSBot> jmiranda: Ticket #1495: http://dev.openmrs.org/ticket/1495
20:06:18 <jmiranda> :)
20:12:43 <Keelhaul> dammit
20:12:55 <Keelhaul> i hate finding something broken and then getting obssessed with fixing it
20:13:03 <Keelhaul> instead of working out and then working on the testathon =/
20:22:29 <jmiranda> Keelhaul: i do the same thing all the time
20:22:41 <jmiranda> guys, i'm taking a short break to make some dinner
20:22:45 <jmiranda> keep up the good work
20:24:07 <nribeka> http://pastebin.com/m73a32364
20:24:11 <nribeka> comments please
20:24:44 <nribeka> or should i just submit the patch?
20:29:51 <nribeka> brb
20:32:12 <Glen_> I'm back now (long weekend here. some family dropped in).
20:33:02 <Keelhaul> nribeka: * @should return all patients without restriction
20:33:15 <Keelhaul> @return non voided patients in the system
20:33:33 <Keelhaul> so there is a restriction
20:35:29 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7818]: groovymodule: Localization of tab names, disable run button while script … <http://dev.openmrs.org/changeset/7818> || OpenMRS Tickets: Ticket #1495 (task created): Annotate methods with @should behaviors for testathon <http://dev.openmrs.org/ticket/1495>
20:38:53 <jmiranda> Glen_: yeah, don't feel you need to be at this all day
20:39:02 <jmiranda> come and go as you wish
20:40:08 <Glen_> ok
20:40:22 <jmiranda> (i know you don't need permission :) ... just wanted to make sure you knew that i'm not expecting anyone to be at this for more than a few hours)
20:41:02 <jmiranda> and i'm hoping this becomes a little more fun and interactive once we start working on the test cases
20:41:40 <jmiranda> in fact, we can move to a more peer coding format if anyone is interested
20:42:01 <Keelhaul> hmm
20:42:12 <Keelhaul> seems like i hit that sql error thats been discussed on the mailing list
20:42:20 <Keelhaul> when i tried loading a new compiled trunk
20:42:41 <jmiranda> nribeka: awesome job
20:43:17 <jmiranda> Keelhaul: with concept_word?
20:43:35 <jmiranda> you should be able to do a delete * from concept_word;
20:43:41 <jmiranda> run the update
20:43:55 <jmiranda> then do a manual refresh of the table
20:44:59 <Keelhaul> jmiranda: yea that
20:45:15 <Keelhaul> jmiranda: why is there a patient_identifier_id now
20:45:24 <Keelhaul> broke my unit tests =P
20:46:52 <jmiranda> that's why we added it
20:47:02 <jmiranda> :)
20:47:11 <Keelhaul> how fiendishly clever
20:49:05 <nribeka> thanks Keelhaul
20:49:10 <nribeka> thanks jmiranda
20:58:15 *** atomicturtle1 has joined #openmrs
21:00:08 <Keelhaul> jmiranda: i cleared concept_word but still cant start openmrs
21:06:41 <jmiranda> Keelhaul: which error are you getting?
21:08:09 <Keelhaul> http://rafb.net/p/ImpIxE57.html
21:22:40 <jmiranda> Keelhaul: yeah, this was brought up by darius yesterday
21:22:53 <jmiranda> the syntax for that is incorrect
21:23:14 <jmiranda> it should be
21:23:42 <jmiranda> something like:
21:23:42 <jmiranda> delete from concept_word group by concept_id, word, locale having count(*) > 1 and min(concept_name_id) = concept_name_id
21:23:47 *** atomicturtle1 has left #openmrs
21:28:25 <Keelhaul> jmiranda: yea, why hasnt anyone fixed it yet
21:28:30 <Keelhaul> i checked it out a few hours ago
21:28:45 <jmiranda> not sure
21:47:13 <Glen_> what does Uuid represent?
21:48:29 <jmiranda> Glen_: universally unique identifier
21:48:40 <jmiranda> used to be guid (globally unique identifier)
21:48:46 <Glen_> ahh ... thanks
21:49:00 <jmiranda> but uuid is a more "universally" accepted term
21:49:18 <jmiranda> guid is apparently a microsoft invention
21:49:33 <jmiranda> i'll be back in about 15 minutes
21:54:45 <Keelhaul> is uuid optional?
21:54:51 <Keelhaul> and what is it composed of
22:06:10 <jmiranda> Keelhaul: it's not optional (i don't think)
22:06:23 <jmiranda> you can use the java UUID class to populate
22:06:36 <jmiranda> it's used by the synchronization code
22:07:23 <r0bby> :)
22:09:41 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Tickets: Ticket #1496 (task created): Syntax error in latest liquibase update script (200905150821) <http://dev.openmrs.org/ticket/1496>
22:19:11 <Keelhaul> jmiranda: what about hsqldb datafiles, what can i put in there
22:19:33 <jmiranda> for uuid?
22:19:42 <jmiranda> it can just be a unique string of characters
22:19:49 <jmiranda> 1
22:19:49 <jmiranda> 2
22:19:50 <jmiranda> 3
22:19:51 <jmiranda> 4
22:20:25 <Keelhaul> o ok
22:37:03 <r0bby> jmiranda: any idea why an object isn't persisting properly?
22:37:21 <jmiranda> because it's not being saved to the database
22:38:00 <jmiranda> did i get it right?
22:38:03 <r0bby> No
22:38:09 <jmiranda> what object specifically
22:38:13 <jmiranda> and how are you saving it
22:38:17 <r0bby> say I load it
22:38:22 <r0bby> :/
22:38:36 <r0bby> it's set as the command object
22:38:36 <jmiranda> where is the call being made?
22:38:41 <jmiranda> ok
22:38:45 <r0bby> in spring
22:39:05 <r0bby> once i can get this working and fix up the the UI
22:39:12 <jmiranda> you need to make sure it's participating in a transaction
22:39:24 <r0bby> let me pastebin my DAO
22:39:28 <jmiranda> ok
22:39:32 <jmiranda> that would be helpful
22:39:41 <bwolfe> why can I not ping svn/dev/openmrs.org. do others have access? :-/
22:40:07 <jmiranda> bwolfe: ?
22:40:13 <jmiranda> not sure i understand the question
22:40:21 <bwolfe> can you access svn.openmrs.org ?
22:40:38 <jmiranda> the servers are all accessible for me
22:40:39 <jmiranda> yes
22:40:40 <r0bby> http://pastie.org/480370
22:40:47 <r0bby> I just pulled down burke' mod
22:40:51 <r0bby> burke's*
22:40:55 <bwolfe> very odd
22:41:28 <r0bby> bwolfe: groovy module 2.0 will be released _VERY_ soon :)
22:41:45 <bwolfe> r0bby: cool
22:41:56 <r0bby> soon as i can figure out what's going on w/ this...
22:42:04 <r0bby> so wanna help me out?
22:42:13 <bwolfe> going to try resetting my connection
22:42:15 <bwolfe> bbs
22:42:18 <r0bby> ok
22:42:21 *** bwolfe has quit IRC
22:43:22 <jmiranda> nribeka Glen_: whenever you want to commit your changes let me know (if you haven't already done so)
22:43:43 <r0bby> I need help :<
22:44:35 <jmiranda> r0bby: so the GroovyScript object is the command object
22:44:47 <jmiranda> spring binds it's values during the request
22:45:20 <r0bby> ok
22:45:25 <jmiranda> what's the URL for the form request
22:45:26 <r0bby> if it has an id field set
22:45:41 <r0bby> hold
22:46:18 *** burke has joined #openmrs
22:46:18 *** ChanServ sets mode: +o burke
22:46:23 <r0bby> burke!!!!
22:46:34 *** bwolfe has joined #openmrs
22:46:34 *** ChanServ sets mode: +o bwolfe
22:46:34 <r0bby> we're discussing why i can't the saving of the forms to work
22:46:46 <r0bby> if i can get this working
22:46:49 <burke> r0bby: wow that took about 0.04 seconds. :-)
22:46:58 *** jmiranda has quit IRC
22:47:21 <r0bby> all i need to do is integrate the buttons to the codemirror editor and do the saving dialog in jquery and we're done
22:47:26 <burke> how goes the test-a-thon?
22:47:32 <r0bby> burke: what can i say, i'm an eager person
22:47:35 <r0bby> I'm not doing it
22:47:44 <r0bby> I'm doing groovy module and having quite a lot of fun
22:47:59 <burke> can you reach openmrs.org now?
22:49:00 <r0bby> hold
22:49:04 <bwolfe> burke: I can't reach it, but justin can
22:49:09 <r0bby> I pulled your changes in
22:49:12 *** jmiranda has joined #openmrs
22:49:12 *** ChanServ sets mode: +o jmiranda
22:49:15 <r0bby> sorry for all the changes
22:49:26 <bwolfe> burke: route must be busted between comcast and openmrs :-/
22:49:27 <Keelhaul> hi burke
22:49:35 <r0bby> i figured i'd prolly get an email :) or you'd change it i just couldn't decide
22:49:43 <burke> hey.
22:49:49 <burke> am i the only one who can't reach anything openmrs.org?
22:49:56 <r0bby> yup!
22:50:00 <r0bby> I can reachit just fine :)
22:50:23 <jmiranda> burke: yeah, i can see it ok
22:50:24 <Keelhaul> i cant reach the web site at least
22:50:40 <r0bby> burke: thanks for those small changes
22:50:49 * burke looks around for DNS
22:50:51 <r0bby> most of this was ripped from the groovywebconsole code :)
22:50:56 <r0bby> 24.29.99.20
22:51:01 <r0bby> try it (it's rr's dns)
22:51:16 <r0bby> who wants to skype w/ me to test this new mic
22:52:02 <r0bby> http://localhost:8080/openmrs/module/groovy/groovy.form is the request url
22:52:06 <r0bby> im posting to
22:52:16 <r0bby> i *THINK* i should know the url by heart :)
22:52:26 <r0bby> mostly firefox helps :)
22:52:48 <Keelhaul> now the site works for me
22:52:48 <burke> r0bby: thx for the dns. that's got me back 4 now.
22:53:34 <burke> oops. just perfect timing. dns is back 4 me too.
22:54:52 <r0bby> burke: only dns url i memorized :)
22:54:54 <burke> r0bby: btw, these groovy module tickets don't all need to be done now (or for 2.0 release). it would be nice to stop long-running scripts though, even if it's just a 30-second auto-kill for now.
22:54:57 <r0bby> s/url/ip/
22:55:03 <r0bby> I know :)
22:55:22 <r0bby> All that's going in 2.0 is the UI changes and saving/reloading
22:55:38 <r0bby> those may be far off since soc is starting
22:55:54 <r0bby> right now i'm focusing on getting 2.0 out
22:58:43 * r0bby sighs
22:58:52 <r0bby> I need to figure out how to update objects :<
22:58:57 <Keelhaul> jmiranda: if you have "@Test(expected = APIException.class)", it actually expects an unhandled exception so if you catch it, the test will fail
23:00:36 <jmiranda> Keelhaul: right
23:00:59 <jmiranda> i was saying that the alternative to @Test(expected...) would be to use a try/catch
23:01:37 <nribeka> i'm on person service now jmiranda, so please stay away from it ...
23:01:41 <nribeka> still on the interface
23:01:48 <nribeka> hi burke
23:01:48 <jmiranda> nribeka: ok
23:01:52 <nribeka> hi bwolfe
23:01:54 <bwolfe> r0bby: make sure your service has @Transactional on it
23:01:58 <bwolfe> hi nribeka
23:02:00 <r0bby> OH DOH!
23:02:17 <jmiranda> nribeka: i'm going to try to commit my @shoulds soon
23:02:22 <r0bby> at the class level bwolfe?
23:02:28 <jmiranda> r0bby: interface
23:02:35 <nribeka> halfway with the person service now
23:03:00 <r0bby> oh each method does
23:03:08 <jmiranda> r0bby: yes
23:03:08 <bwolfe> r0bby: yes, one on the interface
23:03:35 <Keelhaul> bbs
23:03:44 <jmiranda> nribeka: we @should commit soon and start reviewing
23:03:56 <jmiranda> or just go straight into test cases
23:09:07 <r0bby> http://pastie.org/480387
23:09:26 <r0bby> I feel bad for not doing the test-a-thon :)
23:09:36 <r0bby> but i'm knee-deep in groovy/js :)
23:09:58 <bwolfe> jmiranda: whats the plan? are you/me doing @shoulds?
23:10:00 <r0bby> burke: by the way you don't mind that i did it in groovy do you (i know that's been a worry-some point regarding me)
23:10:12 <jmiranda> bwolfe: we're all working on them right now
23:10:12 <r0bby> services are in java
23:10:21 <jmiranda> it's taking more time than i would have expected
23:10:24 <bwolfe> r0bby: so put off the groovy for a day and do the testing. there will always be time to do groovymodule
23:10:28 <jmiranda> i'm about to commit program workflow service
23:10:32 <burke> r0bby: no prob. get it out of your system, b/c your GSoC project will not involve Groovy. :-)
23:10:36 <jmiranda> was thinking we could either review them
23:10:43 <bwolfe> jmiranda: where are we accepting packages/services ?
23:10:43 <jmiranda> making changes, add some, etc
23:10:55 <r0bby> burke: i know :(
23:10:58 <jmiranda> or go straight into creating unit tests
23:11:06 <jmiranda> bwolfe: i just have the google document
23:11:14 <r0bby> burke: actually i plan on sneaking it in (mike ok'd it) in the web layer :)
23:11:20 <jmiranda> i have a list of available classes / interfaces
23:11:25 <jmiranda> you can just choose from there
23:11:44 <jmiranda> or pick something else that doesn't have very good coverage
23:12:07 <r0bby> http://pastie.org/480387 << is that what you wanted
23:12:09 *** kane77 has quit IRC
23:12:10 <jmiranda> bwolfe: http://docs.google.com/Doc?docid=dnc9s5q_38d6kgxfm
23:12:12 <OpenMRSBot> <http://ln-s.net/3CF-> (at docs.google.com)
23:13:01 <jmiranda> r0bby: throw one above "public interface GroovyModuleService extends OpenmrsService"
23:13:07 <jmiranda> as a catchall
23:13:51 <r0bby> ok
23:14:17 <r0bby> god I love Ctrl+Space
23:14:33 <r0bby> @Trans<Ctrl+space> -> @Transactional
23:14:41 <r0bby> works w/ JS too :D
23:14:50 <r0bby> god i love idea.
23:15:08 <r0bby> If i had any idea how to write an idea module for test generation i would :<
23:15:58 <r0bby> sigh time to write the jquery dialog :)
23:17:27 <r0bby> something just crapped out on me..
23:18:15 <bwolfe> jmiranda: are we all just committing the @shoulds ?
23:18:24 <jmiranda> yeah
23:18:27 <bwolfe> or attaching to that ticket?
23:18:54 <jmiranda> i put the ticket there in case nribeka and/or Glen_ couldn't or didn't want to commit to the branch
23:19:35 <Glen_> jmiranda: http://pastie.org/480395
23:19:38 <bwolfe> nribeka can because he has committed to other places before. Glen_ just needs to create a trac account and we can give him commit rights
23:20:20 <Glen_> Hold on. I'll create an account.
23:20:56 * r0bby is r0bby -- the great and powerful...something
23:21:47 <r0bby> I have never seen this
23:21:48 <r0bby> <form method="POST" autocomplete="off">
23:21:55 <nribeka> *ah the perfect song for test-a-thon*
23:21:58 <r0bby> minus autocomplete :)
23:22:08 <r0bby> everything else i saw
23:22:10 <bwolfe> jmiranda: can you give my benwolfe gmail alias edit rights to the testathon minutes?
23:22:45 <jmiranda> bwolfe: done
23:23:39 <r0bby> eh burke you never actually disable the button when you run the script
23:24:48 <burke> r0bby: that's odd. it's disabled in my browser while the script is running -- e.g., sleep(5000)
23:25:19 <r0bby> I didn't run it
23:25:34 <r0bby> I was just eye-balling the code looking for it to be explicitly disabled in the js
23:25:45 <r0bby> perhaps it is
23:25:56 <burke> r0bby: it is. first step in exec() of main.js
23:26:41 <r0bby> OHHH
23:26:44 <r0bby> doh
23:27:11 <r0bby> I <3 jquery so much
23:27:18 <nribeka> i don't have the right to edit it too jmiranda
23:27:35 <nribeka> nyoman[dot]ribeka
23:27:36 <nribeka> gmail
23:27:56 <Glen_> bwolfe: I created a trac account
23:28:03 <Glen_> gmccallum
23:29:17 <jmiranda> nribeka: do you have a gmail account
23:29:28 <jmiranda> nribeka: sorry, missed your next message
23:30:06 <jmiranda> nribeka: added
23:33:40 <jmiranda> Glen_: i added you to the developer group in trac
23:33:52 <burke> r0bby: $('#dialog').dialog({ modal:true, close:function(event,ui) { ... } })
23:34:01 <jmiranda> bwolfe still needs to give you write access to the testathon branch
23:34:14 <jmiranda> i can commit your patch for now, if you want
23:34:46 <bwolfe> Glen_: you have commit access now. I sent you an email about it
23:36:00 <Glen_> bwolfe: jmiranda thanks. I just committed UserService.java
23:36:20 <jmiranda> awesome
23:37:05 <r0bby> ahh bwolf: thanks!
23:38:39 <r0bby> er burke
23:40:10 <jmiranda> bwolfe: should we review the @should's to make sure they're all ok
23:40:15 <jmiranda> or just go ahead and create tests
23:40:18 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Changesets: Changeset [7819]: testathon: Added @should behaviors for all non-deprecated methods. <http://dev.openmrs.org/changeset/7819> || OpenMRS Tickets: Ticket #1497 (enhancement created): Add global header for groovy scripts <http://dev.openmrs.org/ticket/1497>
23:40:35 <bwolfe> jmiranda: I would say its worth you giving them a once-over
23:40:54 <bwolfe> jmiranda: this first time at least. once these guys get the hang of it we can turn them loose. :-)
23:41:04 <jmiranda> bwolfe: ok. although, i'd like someone to give mine a once-over too
23:42:42 <bwolfe> jmiranda: ok, I can look over yours. are they in there now?
23:42:55 <jmiranda> bwolfe: yeah, ProgramWorkflowService
23:43:00 <bwolfe> changeset?
23:43:12 <jmiranda> i got a little lazy at the end
23:43:18 <jmiranda> !changeset 7819
23:43:18 <OpenMRSBot> jmiranda: Error: "changeset" is not a valid command.
23:43:24 <jmiranda> !commit 7819
23:43:24 <OpenMRSBot> jmiranda: Error: "commit" is not a valid command.
23:43:25 <r0bby> burke: I'm beginning to think we should just add a configuration page
23:43:29 <jmiranda> http://dev.openmrs.org/changeset/7819
23:44:16 <r0bby> this module has grown from a Proof of Concept to something kinda neat :)
23:49:48 <nribeka> i steal your commit comment jmiranda
23:49:48 <nribeka> :)
23:49:52 <burke> r0bby: a "Groovy Definitions" or "Groovy Globals" page would look almost the same as the script page without a "run" button our place for output. You'd just edit a single text file of settings. In fact, all of the service bindings could go into it (and come out of the code). Then a "Groovy Manager" page would let you tweak settings and manage active processes. It will rock.
23:50:14 <bwolfe> jmiranda: ok, now try !changeset 7819. I added an alias to the OpenMRSBot for you. :-)
23:50:21 <r0bby> burke: could you throw this on a ticket
23:50:27 <jmiranda> bwolfe: thanks
23:50:29 <r0bby> it's easier to keep track of what needs to be done
23:50:45 <jmiranda> bwolfe: we don't currently check authorization as part of any test
23:50:53 <jmiranda> do you think we should add that?
23:51:05 <burke> r0bby: already did that...
23:51:12 <jmiranda> @should require XXX authorization
23:51:15 <r0bby> ahh
23:51:25 <r0bby> ahh
23:51:44 <burke> r0bby: http://dev.openmrs.org/ticket/1497, http://dev.openmrs.org/ticket/1494, http://dev.openmrs.org/ticket/1493
23:51:45 <r0bby> oh right!
23:51:51 <r0bby> yeh
23:51:59 <bwolfe> jmiranda: yeah, we probably should do that. (or I might say "we @should do that")
23:52:24 <nribeka> 7821
23:52:37 <bwolfe> jmiranda: the test would need to @SkipBaseSetup. and use a normal user that doesn't have that privilege
23:52:48 <jmiranda> bwolfe: i want to throw an exception for this
23:53:00 <jmiranda> comment: TODO Check required fields for user!!
23:53:02 <r0bby> http://dev.openmrs.org/report/7
23:53:03 <r0bby> <3 it!
23:53:28 <bwolfe> jmiranda: ?
23:53:41 <jmiranda> sorry, i want to have an @should for that
23:53:54 <jmiranda> @should have all required fields set
23:54:35 <r0bby> bwolfe: you want the script to be broken up line, by line?
23:54:42 <bwolfe> jmiranda: my feedback on your commit (http://dev.openmrs.org/changeset/7819): Use normal english sentences in your @shoulds: "@should cascade save program workflows" becomes "@should cascade the save to the child program workflows"
23:54:42 <r0bby> and executed line by line
23:54:46 <jmiranda> bwolfe: nevermind ...
23:54:51 <r0bby> which is how I was thinking of fulfilling 1428
23:55:01 <r0bby> in their own threads of course.
23:55:34 <bwolfe> jmiranda: more feedback on your commit (http://dev.openmrs.org/changeset/7819): use the name of hte parameter instead of the generic "identifier": "@should return program associated with given identifier " becomes "@should return the program associated with given programId"
23:55:38 *** burke has quit IRC
23:55:59 <jmiranda> bwolfe: ok
23:56:01 <jmiranda> thanks
23:56:17 <bwolfe> jmiranda: you have some weird spacing on line 107
23:57:22 <bwolfe> "@should unretire workflows" should probably be: "@should cascade unretire to child workflows" to be more clear
23:57:35 <jmiranda> bwolfe: yeah, i was using tab on some of them
23:57:38 <jmiranda> will that not work
23:58:01 <jmiranda> it's just a habit from doing it so much with @param and @return
23:58:13 <bwolfe> jmiranda: it'll probably work, it just looks funny in trac when viewing it
23:58:27 <bwolfe> jmiranda: I don't like it on @param and @return either ;-)
23:58:40 <Glen_> do me next: ( http://dev.openmrs.org/changeset/7820 )
23:58:42 <jmiranda> bwolfe: i'll go through and make it more consistent
23:59:25 <bwolfe> jmiranda: are you reviewing Glen_'s, or do you want me to ?
23:59:36 *** atomicturtle has joined #openmrs
23:59:37 <jmiranda> i was
23:59:40 <jmiranda> but you're better :)