User Story TWILIGHT ZONE…

I’m sorry to inform the masses that I’ve had my first user story QA FAIL. It happened with my Spring Batch jobs. Our BA, who’s testing my story, informed me via Rally that “Criteria 1 failed.” I’m not sure if that’s the first scenario in the user story; or he’s referring to the main criteria, where driver age needs to be the Date of Loss and NOT the age at the time of the exposure date or the current date age. Honestly, I tested the bejesus out of this thing in JUnit testing, and once we pushed it to the test environment I did more testing and checked to see that the correct age was making it to the outbound file—the damned thing WORKED, without a doubt.

I’m not sure what happened. I checked GitHub and there was some sort of change in one of the jobs I altered—tomorrow I have to figure out what the change was, who changed it, and when it was changed. I know one of our other developers had an issue where his code wasn’t working, either, and it was in the SAME job—now whether the change is affecting me or his change to FIX his issue is affecting me, I’m not sure. Previously, I ran his JUnit tests along with mine before I pushed my changed code and neither of our changes had an issue then. Weirdly, whatever changed didn’t alter my actual code change—it’s still in GitHub. If my code didn’t change, then the only thing I can think of is that perhaps someone altered/redefined date of loss in some way…

Unless I can figure this out by eyeballing it, I’m probably going to have to bring the entire March branch into my local and debug to see where the error pops. Maddening.

Build and Deploy!

…or how pushing one button can quickly mushroom into utter confusion.

The good news is that I managed to work through yet another impossible user story. I had some invaluable help from a coworker, who showed me how, in Gosu, to figure out what is being brought into a pcf file, variable-wise, and how to leverage this, by connecting to other fields in the file and join to other files arrive at the field values I needed. He walked me through one example, where I was able to start from the claim file, keep hitting the period, and scroll down until I arrived at the field I needed, and do a string “contains” to spike out the values I needed to filter on. I did the next example by myself and managed to get it! I also learned about the “has match” function. I still have more work to do as I need to use this same method for payments by check, manual check, ACH, etc., but at least I’ve got the logic figured out and the basic code.

The bad news is that my builds and deploys to the lower environments for our area have been less than successful. We all take turns, for each release period, and our agile team was next. The first few times went well (unless you want to count that unfortunate incident where I built TWICE), but yesterday all hell broke loose. Another team in another area, using the same environment name for their deploy, interfered with us, causing everything to be…well, there’s no other way to say it—an EPIC FAIL. Production Support toiled over this and had me rerun the build and deploy, but when I had to log off at 6:00 p.m. it STILL wasn’t working right. My manager isn’t too concerned, as she figures it’s a lower environment, and we can try again Monday.

In other exciting news, I got together with my former Code Academy peeps for dinner last night! Many of us work together in the same office, but we hadn’t really all connected in a while. We went to a huge arcade/sports bar place that had fantastic food. I attempted to do the basketball toss, but failed miserably—I do better in our grandsons’ driveway. We had a fun time, and it was so nice to catch up.

Merge and Purge!

This was one of those days where you think you know what’s going on…and then someone speaks up and all of a sudden you’re COMPLETELY at sea.

After my triumphant completion of my user story, I pushed the code to GitHub and submitted a pull request to my coworker, who is doing my code review. Life was GOOD, until he explained at our daily checkpoint that he couldn’t merge my code due to “conflicts.”  

Heh?  The last I’d checked, everything was fine with my code, and I was able to do a pull request.  Silly me—I’d confused doing a pull request with someone actually being able to merge my code with the release branch.  After the meeting, and after having given blood this morning (the vampires were merciful…I’m only a little bit dizzy and woozy this time) I checked my pull request in GitHub again.  And yes…this is another instance of “Pam needs to learn to read.”  Underneath that nice green “Requested” checkmark I’d been so excited to see, there was a big ugly message informing me that there were conflicts.  I delved into this and realized that when I’d pushed my request, I hadn’t done a refresh from the release branch.  In the meantime, between when I’d checked out the code and done my push, my other coworker had pushed HIS changes to two of the same jobs I’d modified.  Thankfully, I’d saved out my changes, so I refreshed my branch with the release branch, bringing in his changes.  I modified the code with my changes, retested the JUnit tests again, and then pushed the two modified files out to my branch on GitHub.  I’m not sure if I’m supposed to do another pull request or what, so I’m meeting with my coworker tomorrow morning at the crack of down (yes, he’s the one in India) to get some assistance in the matter.

I hope to SOMEDAY understand GitHub…

On a more positive note, I am working on another user story.  I’m very proud of myself, as initially this looked like a completely impossible change that I’d never figure out.  Upon delving into the code, though, I quickly figured out that I only needed to change two classes.  One change uses a series of “else if” statements, which I wasn’t quite sure of how to code—I know how to do this in JavaScript and Java, but I wasn’t sure of Gosu, and I certainly wasn’t going to ask anyone.  Asking how to code an “If-Then” statement or its bastard cousin the “If-Then-Else” or the “Else-Ifs” is probably grounds for someone taking away your company-issued computer, and possibly your lunch money.  All kidding aside, I was too embarrassed to ask, so I ended up scouring the code until I found a similar example and copied that format.  The rest of it I relied on the Guidewire Studio hints to push me in the right direction. It really is amazing how well the application helps you out.  My next task is to try to set up my GUnit tests for this.

But first I must go take some iron and go to bed…

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…

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…

Going Forward…

I’ve been pondering how to move forward with my blog. I know daily spleening about my ups and downs attempting to learn Java and JUnit testing are rather redundant and tedious. I may start blogging two or three times a week. If nothing else, I need extra time to finally make it through my Udemy course!

I’ve also been thinking about how to keep my JavaScript, HTML, Node.js, and CSS skills fresh. I ran into one of my fellow Code Academy classmates, and he mentioned needing to “use it or lose it.” It’s almost like a higher power was speaking directly to me. It’s interesting…our instructor has stressed the importance of having a side project, along with one’s coding at work. In fact, he explained that if you’re looking for a new job, the first thing employers want to see is what you have out on GitHub that you’re working on. I’ve asked around, though, and many developers at work have told me that there is no way in hell they ever have the spare time to do this–especially mothers with small children.

However, I think I have an idea, for something that might encompass keeping up my skills AND having fun with yarn. I’ve been googling. There are TONS of websites devoted to knitting pattern generators (knittingfool.com being one I’ve used), there don’t seem to be any crocheting pattern generators, other than for “graphgans,” which are afghans with a design or a picture on them. There are literally generators out there where you can scan in a picture of your dog and they will spit out a pattern (filet crochet, knitted, afghan crochet, single crochet, etc.) for you to make an afghan with Fido emblazoned on it. I’m thinking I could try a knitting generator, to get my feet wet; but I think I’d ultimately like to make a crochet sweater pattern generator. I’ve tried using ones for knitting, plugging in a crochet gauge instead, but the increases and decreases for crocheting are quite different, AND they’re different for different types of crochet stitches. I DO still have a domain name out there that I bought back when I did my first HTML/CSS project for class…

This could work…

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.