In my last blog, I gave a bit of an overview to testing and why it is important. In addition to different types and scales of tests, there are, of course, also different ways to implement tests. It may depend on your application, the language you’re using, or simply personal style/preference. Switching over to Java from Ruby is an interesting, but not necessarily un-enjoyable experience. In fact, I’ve found it quite exciting, albeit getting used to statically typed code is certainly a steep learning curve…in the beginning, at least.
One thing about Ruby, and why I think it’s typically a preferred language to be taught in bootcamps, is that it has so much ~*magic*~. Alright, not real magic, just that a lot of what is happening in your code is under the hood, and what you actually write in your editor is typically not that verbose and very implied. So the magic is a lot syntactic sugar, I’d say. It’s great in the beginning because what you’re looking at on the screen seems much less intimidating than a beginner Java file would. However, I sometimes struggled with the “magic” of Ruby, because it was challenging at times to grasp what exactly was happening. There might be instances of your code working, but you’re not really sure why. I’ve definitely had a few moments where I’ve been like “omg, it worked! It did what I wanted it to do!” and then I was like “but wait, how? Why? I don’t know how we got here.” LOL.
With Java, it’s not necessarily that things are altogether easier to understand — in fact, often they’re a little more challenging — but because it is a statically typed language, you at least know exactly what you’re working with for every single line of code, and for the most part, even when a method is lengthy and complex, you can figure out precisely what is being accomplished by just reading through it line by line. (I’ve also come to discover that abstraction really makes Java beautiful.) So in the transition to Java, and having never delved that deep into testing in previous Ruby applications, I began to work with JUnit to create test classes for the different parts of my application. Once I started to use it, I really started to see and understand the power of TDD. And because my first foray into a Java application is a fairly simple one (i.e. does not use or create an API, does communicate with the web), I didn’t really have the need for seeding any data (whereas in my Ruby projects, I typically had extensive seed files). But my project still needed something to work with, and in this scenario, it was a simple .txt file.
JUnit’s handiness, especially for a beginner, is in the ability to get to your endpoint, even when you’re lost in your code. While there are many approaches to testing, as mentioned above, for this project, I took a combined approach. I didn’t necessarily start out with the tests and then write my main java files, nor did I “complete” my main java files and then write tests just to back up that they did what I intended. I used the two in tandem. After initially sitting down and modeling out what I thought the application should look like, thinking through the design and what methods, properties, and capabilities should be relegated to and/or contained in specific classes, I would start to structure the initial setup of the class and typically get to where I thought I was returning my desired result, (especially if I could print that result in the console), and then maybe attempt a very rudimentary test for verification. At the outset, this was straightforward enough but as the application grew in complexity, with ever more files interacting with each other, and more packages imported, simply creating code I thought would work became an uphill battle.
As I started drawing in my code, and event in the overall design of my application, the power of JUnit truly revealed itself. I could step back, and re-evaluate what I was doing, what I was achieving, and where I wanted to go from there. So I would start to write one method to accomplish a prescribed outcome and if it used other class methods or started to become lengthy, I would stop and go work on a test just to make sure I was on the right track. From there I could begin to tackle the class interaction and abstract overly large or complex methods.
So perhaps in an example where there is a User class, creating the new User might be fairly uninvolved, especially if it’s the initial and primary objective. But if the User needs to be able to execute certain functionality, like say, sign up for an event, then we’ve got another class Event, and maybe another class, SignUp, that all start to rely on each other to efficiently create the application as a whole. Even though Ruby is an Object-Oriented language, having come from using the ActiveRecord ORM, this process illuminated and reiterated how a lot of how that interactive logic is sort of handled for you ~*magically*~. Whereas with Java, also Object-Oriented, the interaction can get a little hairy (especially without relying on too many outside tools and as a newcomer), to say the least. After verifying that a User can be created, adding and being able to jump into EventTest and SignUpTest to make sure that all are are accurately relating to one another isn’t just helpful, it’s imperative.
Sources
— https://junit.org/junit4/faq.html
— https://www.guru99.com/junit-parameterized-test.html
— https://blog.parasoft.com/how-to-create-junit-parameterized-tests-faster
— https://dzone.com/articles/junit-parameterized-test
— https://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/testing.html
— https://www.baeldung.com/parameterized-tests-junit-5
— https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests-argument-conversion-explicit
— https://blog.codefx.org/libraries/junit-5-parameterized-tests/
— https://en.wikipedia.org/wiki/Mock_object
H^2 