Sunday, September 22, 2019

#CodeConfident: Journey - Part 3

The preparations for my upcoming talks at TestBash Manchester and Agile Testing Days kept me pretty busy the last months. Despite them needing lots of attention, I made some further progress on my Journey application to be shared here as part of my coding journal.

September 1

  • compiled todo list for Journey as preparation for next weeks and next pairing session: what to do before my TestBash Manchester talk about my #CodeConfident challenge, and what I could do any time
  • I'm still considering using the GitHub project board feature to make ideas transparent and keep track of them in the future; for now I postponed the decision to a later point when I have more capacity for it again

September 2

  • pairing session with Michael Kutz
  • before we got started we had a great chat about exploratory testing, quality indicators, giving workshops, and the difficulties of switching between developer and tester mindsets :)
  • I explained the project background, what got generated by JHipster and what not, as well as the general purpose of the app and the open todos that I see as of now
  • Michael chose to help me use Lombok to get rid of some boilerplate code (we also use Lombok at work)
    https://www.projectlombok.org/
  • Michael explained that Lombok is executed before Java, Java ignores the annotations
  • first we checked that I had actually already installed the Lombok plugin for IntelliJ
  • we added Lombok dependencies to the gradle build script
  • added the Lombok @ToString annotation to the Challenge class and removed the related method; in the structure we could now see that the functionality still got generated as virtual method by Lombok
    https://www.projectlombok.org/features/ToString
  • to see if things are working out we created a minimal test for this method; it's questionable whether to keep it or not - on the one hand we trust Lombok, on the other hand sometimes maybe not
  • learned a new shortcut to create a test: press Alt+Enter on the class name; for Java it's good practice to keep the test in the same package structure to have access to protected methods; using this shortcut the test will automatically be created in the same structure in the test package
  • JHipster generated the integration tests right next to unit tests; Michael normally keeps integration tests separate, as we also do at work
  • Michael saw that the generated unit tests had been created as public; he shared that this was needed for JUnit4 but is not anymore for JUnit5 so this access modifier can be removed to use default access within the same package instead
  • Michael instructed me when writing this simple test; we kept it really minimal having it only check if it contains a defined tag; if we would keep it we would implement all kinds of checks here
  • when running the test using the IDE we noticed that Lombok had not been recognized; we realized that we needed to activate annotation processing first for the project in IntelliJ
  • now @ToString was working!
  • we tried out the @Data annotation next which includes toString, equals, hashCode, getters and setters implementation
    https://www.projectlombok.org/features/Data
  • we removed the related methods and kept the builder methods that can come in handy when writing tests
  • to see if everything was still working we ran the related integration tests and saw that one test failed: equalsVerifier()
  • we checked this generated test and saw it was very generic
  • we debugged the test to see what happens; I learned that you can simply right-click on any previously executed test and directly re-run it from the offered context menu
  • we could not see yet why the test passed for the previously implemented equal method but not for the one generated by Lombok; and here we ran out of time
  • I learned that you can run gradle commands in a shortcut format, using only the initials of the command; e.g. instead of "gradlew integrationTest" just use "gradlew iT"
  • when trying this I learned that commands were not executable on Unix machines; Michael shared that you can run "gradle wrapper" to set the missing permissions; yet this failed, reporting an error in the gradle file! Another thing to look into
  • Reflection:
    • Michael: it felt like you were using IDEs for years already, you seemed quite code-confident already; you only waited for instructions when it came to writing the unit test, not sure what this was about; Lisi: I had a blackout in this moment, happens to me quite often especially when pairing, often have to look up syntax; Michael: especially as you shared you switch between different languages - I mostly stayed with one which then becomes second nature, routine
    • Michael: really likes pairing a lot; it's super important to read documentation together, to stay on the same page; was happy to navigate me through; Lisi: the session was super insightful and it was very pleasant to pair with you! I was happy to drive and have you navigate, especially with you sharing lots of knowledge, thoughts, your intention, shortcuts to increase efficiency and more.
  • TODO: check: when preparing for the session, it seemed that I messed up liquibase as the checksums did not match on first startup with a fresh database; yet later Michael said he could start the app without problems
  • TODO: when cleaning up, also separate integration tests from unit tests
  • TODO: make gradle scripts executable and commit, they are not running out of the box on a Unix machine
  • TODO: make unit tests private
  • TODO: investigate reported error in the gradle file
  • TODO: investigate failed test when using Lombok and fix, test if everything is still working, then switch to Lombok

September 8


September 15

  • GitHub reported a security vulnerability, asking to upgrade generator-jhipster to version 6.3.0 or later. The details stated it's of critical severity:
"GHSA-mwp6-j9wf-968c 
Vulnerable versions: < 6.3.0
Patched version: 6.3.0
Account takeover and privilege escalation is possible in applications generated by generator-jhipster before 6.3.0. This is due to a vulnerability in the generated java classes: CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) 
Generated applications must be manually patched, following instructions in the release notes: https://www.jhipster.tech/2019/09/13/jhipster-release-6.3.0.html"
  • upgraded version and adapted the RandomUtil class as suggested
  • ran all tests
  • found that e2e tests tried to run with outdated chromedriver for Chrome 74 instead of 76
  • yet upgrading the related npm package still used the old one
  • could run e2e tests using protractor directly instead:
    npm install -g protractor
    webdriver-manager update
    webdriver-manager start
    protractor src\test\javascript\protractor.conf.js
  • found that three e2e tests now failed after some recent changes where I forgot to run them before; one was asserting for text that I changed, updated this one; two are failing due to changed pagination - need to think of a better solution here for assertions, need to revise these generated tests anyway
  • TODO: refine e2e test assertions for creating & deleting journal entries without depending on pagination configuration
  • TODO: find out how to run e2e tests with latest Chromedriver

September 18

  • reconsidered the open pull request from Toyer Mamoojee to remove Chai as superfluous additional framework
  • the suggested changes did not work out of the box, but threw the following errors: ReferenceError: expect is not defined and WebDriverError: element click intercepted
  • googling did not result into a quick solution
  • decided to keep the tests as they for now and pair on them later on as they need general re-work anyway
  • commented on the PR accordingly and close it for now

Two Exciting Talks Coming Up

TestBash Manchester is getting closer and with it my talk about my #CodeConfident challenge. I had two test runs already, one with members of my power learning group and one at a local meetup. The resulting feedback was invaluable to improve the talk further before going on the conference stage. A special shout-out to Toyer Mamoojee, João Proença, Viktorija Manevska, Simon Berner and Patrick Prill! Thank you all so much. The talk is already a lot better because of you.

About a month later, it will be time to enter another keynote stage. I'm feeling especially honored by this fact because of two points. First, it's the keynote stage of Agile Testing Days - the very first conference I've ever attended back in 2015. Second, I will go on this stage together with Toyer, sharing our personal journey as learning partners. If you wonder how it came to that, check out my latest guest post "What a Journey! From Conference Participant to Keynote Speaker" on the Agile Testing Days blog!

No comments:

Post a Comment