2025-06-13 - Day 13 - 100 Days of Cdoe

Hello, Friends -

A day or two ago I moved my copy of coding problems (Leetcode, Hackerrank) out of some journal notes and into their own repo. Today I tackled the question: How do I test these? I don’t want to manage testing frameworks (Mockito, JUnit) or set up external dependencies (Maven or Gradle) for this project so the testing here is very BARE BONES. There were options when making this decision. I could have:

1. set up a complicated file system and include Maven or Gradle - pom.xml or build.gradle plus any dependencies plus goals or plugins. OR
2. set up a complicated file system and do not include Maven or Gradle build tools - then you’re running tests from a completely separate directory which adds an unecessary level of complexity for these simple coding problem solutions. OR
3. do not set up a complicated file system, add test classes as separate files in the same directory as the code problem classes. Then the tests can be run separately from the solution class. OR
4. do not set up a complicated file system, add test classes DIRECTLY into same document as the coding problem - then the tests can be run at exactly the same time as the solution. Now we’re talking - simple and easy!

Can you guess which I chose?

These mimimalist tests require a flag: -ea which stands for -enableassertions because the keyword “assert” was not always a keyword, it was (in the distant past) not a reserved word. So today you can use “assert” in some light testing and run the *.java file with the -ea flag. If you run the *.java class file without the -ea flag then nothing happens, they are ignored. NOTE: there is no output for these assertions if they agree, but you will get an assertion error if they do not agree. I added a print line in my test just to show they at least ran. https://www.baeldung.com/java-assert

Today’s hour of coding for the 100 Days challenge stretched out into three hours. It breaks down to 30 minutes of actual code writing and the remaining balance was tool fighting. I REALLY HATE TOOL FIGHTING. However, I absolutely must expect this. I’m trying to spend more time with Windows and Azure and other MS products so there will be a learning curve. Cross-platform tools like VS Code do not come close to functioning the same in both Windows and Mac so I’ll have to get used to the differences. Today this included a lot of learning how to get VS Code to run and test a small Java program (like a miniscule 30 lines) without building a jar file, without Maven or Gradle, and without complicated file structures. It is not as straightforward as one might imagine, and the solution included a plot twist I did not expect - run a command pallette “Clean the java language server workspace”, which I have never heard of before.

Here’s a reminder of my current/ongoing projects:

1. Coding problems
2. Eensy ETL
3. Exercism (you don’t know about this one yet)

Tomorrow expect more updates from the Eensy ETL. Stay tuned…