A few weeks ago, I was introduced to JUnit testing in my Software Quality Assurance & Testing course. The blog post tutorial linked below is one I would recommend to those interested in learning about assertion. Reading this post has helped me review the concepts I have learned and I will share what helped me better understand the topic of writing basic assertions with AssertJ.
I found this content useful as it started off by covering whether a user had Maven or Gradle for declaring the dependency and then we get to dive into scenarios when a certain feature would be used. Some examples of what you can test with assertions includes: boolean values (true/false), whether or not something is NULL, comparing the result with a number or string (EqualTo()), object references, and arrays that are equal.
There is a walk-through of what we want to test with a basic scenario of when we would want to use it and this information makes me appreciate how much this kind of testing helps simplify things. It adds more structure to what we would like to do and by being able to import it, saves us so much more time in the end.
Honestly, in class I tend to spend more of my time trying to follow steps instead of absorbing what the material is and this article really helped me realize things like “oh, so this is why we use this line of code” or “so that’s why this is always there.” As a visual person, I appreciate the articles which actual include code examples for us to see what’s being used or added to explain a concept which was very helpful in this case. I do not disagree with any of the content provided as it is much more technical and there is reasoning behind each part of the process.
Overall, I would keep this article bookmarked and may come back to use it as a reference whether it be for a future testing assignment or just for trying to refresh this in my memory. As a side note, installing gradle on our laptops in class enabled us to run our tests through the terminal which was a pretty cool experience.
In my software design course, I recently learned about how using design patterns helps you code better. I thought it would be a good review to go over the concepts this article introduces and potentially link it to things from class and maybe even add some things we did not get through during class.
“Forget about automating your regression tests” is some bold advice from Bas Dijkstra, who has experience as a test automation consultant. It made me wonder what exactly led him to making this kind of statement on regression test scripts and his article, On Ending the Regression Automation Fixation, covered various reasons why.
As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.
After learning some life lessons through the pages I’ve skimmed from my copy of The 7 Habits of Highly Effective People by Stephen Covey; this article’s version for software developers in test caught my eye. What exactly are the seven highly effective habits of SDETs? Here are the seven habits that Angie Jones, a senior developer advocate at Applitools, wrote about: being intentional, enhancing development skills, enhancing testing skills, exploring new tools, automating throughout the product’s tech stack, collaborating, and automating beyond the tests.
According to music artists, two is better than one. When it comes to designing code that has two parts, this may not be the case. In Max Kanat-Alexander’s article, he explains how he has a personal rule of needing to know how generic his code needs to be. He describes it as if he were designing an audio decoder and started out with supporting WAV files and then later needed to add support for MP3 files. His solution was for what he only needed on its own instead of having to copy and paste the common parts for the format; he emphasizes that “it’s not just two implementations that are bad, but also two locations.” Another rule Kanat-Alexander has for helping this stay consistent is to create code well enough to ensure you would ideally never have to go back and change it if another part of the code has to be modified.