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.
The three categories Frederico Haag, a computer science engineering student at PoliMi, wrote about are creational patterns, structural patterns, and behavioral patterns.
Based on the design pattern I chose to work on for my individual assignment, I wanted to focus on the facade section–which is a structural pattern. The main take-away of the facade is how it “provides a simplified interface to a larger body of code.” I like how the name itself actually relates to the word facade’s definition: “an outward appearance that is maintained to conceal a less pleasant or creditable reality” (Dictionary.com). As a person who likes the aesthetic side of things, this seems like a convenient design pattern, especially if people who are not working on the code end up seeing it; it may be less overwhelming to some.
Another one of the options my class had for the same assignment above is for the decorator class–which is also a structural pattern. This “adds behavior to an object dynamically without affecting the behavior of other objects from the same class.” For some reason, when I imagine this concept, I think of a decorated cake. Since it is useful for adding the same behavior to many classes; it’s like when you add a spread-out layer of fondant or frosting to a cake, it could either cover the whole section(s) of cake or just some, but it doesn’t mess up the inside of the cake.
Overall, I found this content very useful to reiterate what I had learned and Haag incorporated visual UML diagram examples along with actual snippets of code to help us compare and contrast what he was showing. The content has not changed how I think about the subject because there is no arguing here, it just shows different ways people can structure their code overall. I do appreciate how Haag also listed “typical use cases” for some of them as it makes it easier to imagine.
Hey guys! Something I’ve been thinking about for a while finally became real, I created @samfitnessed on Instagram.
Feel free to follow me if you may be intimidated by the weights at the gym, need ways to stay fit outdoors or at home, or are just along for adventures; this is the fitness account for you!
“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.
Two reasons why Dijkstra says starting with automating your regression tests is not ideal includes regression scripts being too long and how regression tests are written from an end user perspective. I find this interesting as a lot of software bloggers are saying automation is not always going to be the answer and their answers have yet to make me disagree.
The reason I chose this is because I am drawn to honesty; two examples above were explained with scenarios with failures Dijkstra has faced from creating inefficient or “plain worthless” cases.
This content will change the way I think about creating potential testing cases as there will be questions to ask myself before proceeding with the task(s) at hand. There will be a lot of reflecting on what could be consuming my test time, which parts are too repetitive, or what can just be done better. I mean of course I’ve already been considering these questions but now there will be a more conscious effort to think about them.
Dijkstra’s process especially considers the difference between how many scripts there could be when a computer is trying to translate what a human could have performed when testing. I realize how that would be an issue when trying to understand what could have went wrong or does not match up fully when there is less (specific) feedback when it comes to automation.
Thanks to this article, I will also try to predict how many layers of regression scripts would be too much of a hassle to develop ways for communication between what is being tested under the application. Overall, this information was useful as we should be reminded that “automation is meant to make your life and testing applications easier”; it should make sense and not be done at random, especially for regression testing.
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.
Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.
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.
If anyone is interested in becoming a SDET, they should follow Jones’ advice as she is very familiar with interviewing SDET candidates. Something thought-provoking about the first one is how automation projects are not always the best option. Before this article, I understood that not everything required automation but it was the end goal for more projects or companies overall. This is due to my experience; for some reason I believed that just because the company I was at wanted automation for something that everyone else would too. After reading this, I am now understanding that automation is only the goal when it is aligned with the overall outcome.
I am noticing a consistent pattern of guides to becoming a good software developer or tester containing similar tips like “enhancing development skills” and “enhancing testing skills” as people in this industry must always keep learning to stay on top of what’s new. Due to the repetition, I have been trying to keep an eye out for the more unique ideas. One of the ideas that stood out to me more is the one of collaborating.
Jones listed careers ranging from business analytics to software development and mentioned how they would be good matches for pairing up with SDETs to help each other better understand certain features and the importance of what they will be working on. From a sociological standpoint, I like this approach to finding all the resources to complete a project outside of the department. As someone who is always looking for ways to connect with people or connect people to other people, this is an effective idea for helping companies and their people feel more at ease with their jobs. The SDETs may feel less pressure knowing they are not entirely on their own and can request help when necessary.
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.
I found this information useful because I believe that developers are always striving to be the most efficient coders they can be. In order to do so, using two of Kanat-Alexander’s methods would help them plan to code more effectively. Just imagine the potential headache of realizing you have to go further back to code you thought was finished and then even further back when you notice a change on top of what you originally needed to make. This will probably affect how I will work in the future as it will make me sit back and think beyond the task at hand. It would allow me to save room for potential add-ons without them crisscrossing, which would allow me to skip out on having to do more rework.
At the end of the article, Kanat-Alexander notes that the reader does not have to take this as a “hard and fast law of the universe” and I appreciate how he tries to help the reader but does not try to push them to do it his way. In terms of the subject, I do not think my thoughts have changed too much as I do want to learn how to code better and I would like to continue finding out about people’s coding structure process.