Tag: coder

HappyDanceHappyDanceHappyDance!!!!

I DID it!!! I finally figured out what I was doing wrong with the JUnit testing. There is a line of code at the beginning of the test for a field that says “contextData.” Initially, it appeared to be some sort of memo or reference. As I’d exhausted every other option this week, short of Voodoo chants, I checked the field again and…I was wrong! Far from being a “memo field,” the code is actually used to pull in the data elements that have been changed in the payload. So, in my instance, I needed to add Date of Birth, Loss Date, and Driver Age to this string, separated by pipes, so that these are be accounted for in the test.

As a result, I’m FINALLY returning data, and the correct data to boot! I need to write up more JUnit tests for different scenarios, but at least I now understand how these particular ones work.

I also participated in a fire drill today—okay, it was more like a full-on 5-alarm blaze. Our BA (you remember him—the poor bastard who inherited all my work when I went off to Code Academy last July) found out that one of the user stories for his other agile group tanked in regression-testing. The developer who worked on it is offshore and was one of the many who was off for Pongal. It was my boss’ idea to put me on this as a learning experience, with the other developers. We all checked different things to see why this wasn’t working. My task was to scour the past release’s code for anything to do with the logic that was broken, and then compare to see what was overlooked and/or changed by the user story code in this release.

THEN, it occurred to me…I asked our BA, “What exactly DID the error message say?” I searched our GitHub repository for the exact wording, and FOUND it! The odd error message came from one of the new Gosu rules (.gr file) the user story added. I did my best to figure out what on earth the code meant that led up to it throwing an error. The other developers had in the meantime found other odd things to do with the test environment, so hopefully between all of us the group can determine how to fix the issue.

I have to say it was very exciting to discover that I can in fact troubleshoot code I had nothing to do with writing, and understand it! This is pretty good, in that I’m hopeless at troubleshooting knitting and crocheting mistakes for people when I didn’t personally create the article.

Now back to the JUnits! I’m hoping for a peaceful Friday to complete them…

Fun with JUnits

…or, why I’m pretty sure I’m grayer than I used to be…if I wasn’t in fact hiding my gray. 😈

The good news is that I’ve had a crash course in working with Spring Batch and I’m now a veritable expert in operating the debugger. I also now understand (somewhat) where to get the data for the payload by running only a few SQL queries against the test data from the UI and using the resultant payload for our JUnit tests. This is definitely a step up from my attempts to get data last week by running multiple queries and cutting and pasting all the information!

Monday, my coworker spend an hour of his life he’s never getting back showing me all this, while attempting to help me with the payload for my testing. The payload still isn’t exactly what one might call stable. I tested with and without my code change and thankfully that’s not the issue–I would have run screaming into the night if it was.

Sadly, I’m going to have to have him help me further, as I ran all the SQL queries I was supposed to to get my new example, but I’m not ending up with the same file format that our JUnit job requires. I’m not quite sure WHERE my coworker found the information, but I don’t think I quite have it.

The adventure continues…

Work Day 50: Seeing light at the end of the tunnel…

…that we really hope isn’t the on-coming train!

I’m making slow, but steady progress on my JUnit issue…if you count “finally finding the right people to consult” as progress. My poor, long-suffering mentor is inundated with work for the upcoming release, so he’s tossed the ball back into my team’s court (you know it’s bad when I’m resorting to sports analogies). One of my team members figured out part of my issue. I definitely had no access to get a Nexus Repo Key for that Maven step for setting up Spring Batch. The good news is that I put in a tech support request, and I got access to get one—miraculously in one day! At that point, I was totally fried, so I’m going to attempt to do this tomorrow.

This brings me to the bad news. The other person on my team who’s helping me…he’s in India. Yours Truly is going to get into work at the crack of dawn tomorrow morning to be ready to talk to him at 8:00 am. As much as I’m very grateful to him, this is going to cut into my morning yarn time! In addition to my sock-knitting, I’m also crocheting the Sophie’s Universe Afghan, which requires early morning quiet time, in order for me to concentrate. It’s one of those maddening patterns where, even though I’ve had oodles of years in crocheting experience, I’m still frogging back practically every row, due to being hopelessly off in stitch count. I’m only a few rows in, so far!

Work Day 49: Training and more training…

…or, am I EVER going to figure out all this stuff?

This morning we had another CodeAcademy continuing training session — this time for client-side JavaScript testing. We worked through Mocha and Jasmine examples, with our takeaway being to modify the code to add to the constructor, and experiment with different tests. While I can understand this kind of testing, I’m still struggling with my Java JUnit testing for my user story. I cannot get my JUnit test to work in Eclipse. In looking at it, and comparing to other JUnit tests in our code, I think I’m missing a few things, and oddly, my test isn’t “tracking”—I’m getting an error saying the class isn’t “found.” As it is, though, none of the JUnit tests are working for my setup, so my issues may run a bit deeper than just a few misplaced @Test indicators.

I decided to eat crow and work through a Pluralsight video on JUnit testing. I’m also going to try to make a push to work through more of the Udemy course, as they do cover JUnit testing further along in the course. I even bought a book on JUnit testing (Pragmatic Unit Testing in Java 8 with JUnit by Jeff Langr—God Bless Amazon…). Hopefully with all this and having my mentor help me out (I’m going to need help setting up Spring anyway), I’ll muddle through.

All this setup and testing for a few lines of code change…it’s just unbelievable!

Work Day 48: My new toy!

I can’t remember if I’ve mentioned it, but back when I was frantically trying to make ClaimCenter 9.0.7 work on my local machine, one of the things I had to do was to hook up my database. As I was adding in the drive path into the configuration file and the h2 jar file, I discovered something wonderful. To test the database connection, one clicks on the h2 jar file, and then clicks “Test Connection.” If “Test Successful” pops up, then you’re good. Now, you’d hit “Connect.” WELL…when I did this, a SQL window popped up, with all the data files listed, such as you’d see for the test and production Oracle environments in Oracle SQL. For hoo-has, I experimented and plugged in one of my production queries, minus the “gwcc” prefix, and IT WORKED! I now have a way other than the Gosu Scratchpad to query my local database to see what it contains! I proceeded to try all my queries and they all worked. The only ones that don’t are the integration ones, as that information wouldn’t be under this schema.

Speaking of integration, I found out that our integration repository for March won’t be out until next week. In the meantime, I’ve still been trying to familiarize myself with Spring Batch. One of my coworkers, who deserves a medal in sainthood, was trying to show me how to create JTests for my integration code change…he was saved by his ride arriving to pick him up. While it was somewhat confusing, I think I got the gist of what he was showing me, so I’m going to continue on with it tomorrow.

Work Day 47: Well, I THOUGHT I was brilliant…

Remember my great stroke of genius in discovering I’d only need to add one argument to pass to that one method to fix the driver age being passed to our other system?

There’s good news and bad news. The good news is that my mentor helped me determine the correct version of the integration repository to clone to make my changes (short answer: it doesn’t exist yet for the March release). He helped me with my Eclipse setup, so that I can eventually make my change—for now, I’m using the older repository code for this purpose. Creating a patch in Eclipse is similar to creating one in Guidewire Studio.

The bad news is that my ingenious idea to add one argument to pass into the method was a bust. I added my change in Eclipse only have have all sorts of angry little red Xs and other ugly notations pop up. Come to find out, I hadn’t thought to DEFINE the loss date field that gets passed with date of birth. Choking down my rising hysteria, I saw how date of birth was defined, and then I scoured the class until I found loss date defined somewhere else in a similar manner. I copied that code over to the code that calls the method and all the angry little squiggles went away! Whether or not this actually will work remains to be seen. Once the March repository becomes available I’m going to hook everything up and test by entering some claims into my local UI and see if they pass correctly through the integration process.

Okay, that’s how I imagine it’s going to go. I’m sure the reality is going to 12 times more complicated than that. For one thing, I have to make this change work for five different scenarios. Also, I’m casually using the expression “hook up” for a process that’s defined over 11 pages of documentation.

My poor mentor is going to deserve a medal for this…or at the very least hazard pay…

Work Day 45: Back in the Saddle Again!

…but what on earth are my passwords???

It was a very nice holiday break marked by good times with our family and friends, a few cleaning projects, finishing knitting projects, endless cookie-baking, and five extra pounds I need to get rid off. Alas—what with all the preparations, festivities, tinkering with new gadgets I got for presents—I only got in ONE Udemy Java course session. The good news is that I hadn’t forgotten anything, so I’m hopeful that once I get past the 3,456 emails in my inbox, that I’ll be able to be somewhat functional.

…these were my thoughts BEFORE I got back to work and discovered we’ve gone from ClaimCenter 9.0.5 to 9.0.7. The email went out last week, when most people were out for Christmas. I had to update Guidewire, add in code for my two user stories (story #3 was usurped in my absence, due to requirement changes), retest them, and push everything out to GitHub for a code review again — for FRIDAY. It took until 2:30 pm just to have 9.0.7 fully functional in my local. My only consolation was that I wasn’t alone—other people had a ghastly time attempting the change. I took copious notes for the next time we have to go up a version, including additions to my ongoing error file, where I note down all the errors I’ve encountered so far and how to resolve them.

And a Happy New Year to you, too!

Work Day 44: Wrapping it up…

…only a WEEK left to shop!!!

I’m about to be off for the rest of the year, so today was a day of frantically wrapping everything up at work. With a coworker’s help, I managed to solve my role story issue—I even crossed the big frontier of modifying a CLASS…with a new FUNCTION! Okay, he had to help me write it correctly in Gosu, but I did manage to figure out where it would go and what it would need to do. I even managed to avoid a tech-debt situation by putting the code in a class rather than in the pcf.

I don’t want to lose the knowledge I’ve gained, so in addition to my frantic holiday shopping (yes, I’m one of those people who runs out at the last minute), I’m also planning to spend time every day on my Udemy Java course, and reviewing the Gosu documentation.

Oh, and of course there is important knitting and crocheting to be done! I’m making progress on the sweater I’m planning to wear for Christmas.

img_1405-1

Work Days 42 & 43: Surely You Mock

I know…I’m combining TWO days in a row. In my defense, one could consider these two days to be a continuation of each other, as I’ve been in Gosu hell since yesterday. Unbeknownst to us, someone–in the interest of anonymity, we’re going to call him Earl–pushed a GUnit test (like JUnit tests, only for Gosu) that uses Easymock 4.0.1 out to the release branch. Fun fact: many of us are still on Easymock 3.1. I found this out the hard way when I needed to do a fix for the role user story, but was dead in the water when I got two compiler errors after creating my branch from the release branch.

Come to find out, this has been an ongoing drama of “Dynasty” proportions since December 5. For my younger readers, that would correspond to “Real Housewives of Beverly Hills-on-steriods” drama, like that chick screaming to the cat in all the memes.

Anyhoo…The initial alarm was raised in home office with–in the interest of anonymity we’ll call this fellow Gungho Carl. Gungho complained back on December 5 that he couldn’t compile. Gungho is actually a kickass developer of uber nerd cred, so if HE can’t compile, there’s something seriously WRONG. From there, for the next several days, there were a flurry of frantic emails back and forth with basically the known Gosu world within my company. The news eventually filtered down to our office in the sticks, and landed with my mentor. He’d only informed a few people about how to fix this (including Earl), as I don’t think he realized how many of us were still on 3.1.

Per his instructions, I updated to Easymock 4.0.1, fired up the server, and…drum roll…

I got 1,018 compiler errors!

As a temporary workaround, because I was really desperate to get my user story changes done and into GitHub, someone (The Alum) had me just modify the other guy’s GUnit test in my local machine to use a parameter in keeping with 3.1 (the test didn’t affect anything I did).

My mentor, who was NOT PLEASED with the workaround, helped me today to get updated with 4.0.1 correctly.

In other news, I was shown how to do Git commands from within Guidewire Studio! I haven’t created a branch from there yet, but I managed to add, commit, and push my changes. Very exciting.

I’m also happy to report that I just checked, and TWO of my user stories are now in the Release Path!

However, as of this writing, I still have MORE work to do on my role story. This is my favorite screw-up category called “Pam needs to learn to read.” I created my role, but apparently someone felt it needed to WORK. Go figure. To be continued tomorrow…

Work Day 41: Making it official…

I’ve decided that I’m just not right in the head…remember that defect user story I was scoping out—the Penalty Payments from Hell? We were having our checkpoint this morning, and we were discussing backlog items. One person grabbed the Integration story (oh, DARN). That left my nemesis. Remind me never, ever again to jump in feet first during a lull in the meeting conversation. As no one else was leaping up and down for the payments defect story, YOURS TRULY decided to be plucky and volunteer to do it. Granted, I did indicate that I might need help, but in looking it over, I think I’m going to need a BOATLOAD of help. For one thing, l have no real way to duplicate the issue on my local machine, due to having no connection for checks. I think I’ll need to see if there’s some way to fake a check payment going through—otherwise, I’ll never see what’s happening with the button behavior.

Thankfully, the release date for this is March. I think my first plan of attack will be to go over this with our product owner and our BA, to make sure I’m understanding what I’m supposed to be fixing in the first place. I realize I probably should have come to that conclusion at 9:00 a.m. this morning, rather than at 5:00 p.m., after an entire day of trying to trace through tons of code in an attempt to understand the general process. The good news is that I think I’ve pinpointed where the roles and security get determined in the code…

One a more cheery note, I had my knitting group this evening, and I’m finally done with both sleeves and body of my sweater! I just have to now join everything for the yoke.