When coding, users always have to be conscious about the way their code may be implemented or used in the future by different services leading to potential misuse. After reading Code Health: Make Interfaces Hard to Misuse by Marek Kiszkis, it made me think about how important communication between testing code is.
I found this content useful because Kiszkis featured some examples that can show how an interface could be misused easily. The examples included:
- Requiring callers to call an initialization function
- Requiring callers to perform custom cleanup
- Allowing code paths that create objects without required parameters
- Allowing parameters for which only some values are valid, especially if it is possible to use a more appropriate type
It is also good to remember that at the end of the day, code should be defensive but not too defensive to the point that complexity is increased and performance overall is reduced. Kiszkis says “it is not always practical to have a foolproof interface” because there will be situations where some requirements are things that cannot be expressed in an interface.
After seeing so much content based on being careful about what you code it is surprising how this article says it is not necessary to plan too hard. I kind of understand why Kiszkis would say this but personally, I kind of disagree with this. The reason why I disagree is because if someone does happen to end up with more time to work on something than expected and they know it will make something more efficient, then why not go for it?
Overall, I appreciated what was shared in this article in terms of encouraging users to try and see issues that can arise with their code when it comes to interfaces. The main takeaway for me is that if something is brought up, or triggered by undefined behavior, a user should try and make it impossible for this to happen. A way of doing so is by adding things where necessary, like certain slots in his example. It does not have to be too specific but detailed enough so that it covers different aspects, similar to how we try to prepare for everything when it comes to equivalence class testing.
If you happen to be reading this page translated from English to another language, hello there, you are one of the main characters of this blog post. Without linguistics, the study of language and its structure, we probably would not be able to figure out how to communicate everything we need to globally while being able to understand it at the same time while testing. There are so many online resources that cover what a specific country or region in a country uses in terms of data formats for their computer systems.
Stickyminds featured an article from Mukesh Sharma on Linguistic Testing: Setting Up Your Software for Global Quality. Sharma dives in by explaining what exactly linguistic testing is–which is testing not only localization but also internationalization. These words basically mean everything we are testing on the software either is or would be fully functioning across the globe.
I found this content thought-provoking as I never specifically thought about how developers and testers would have to consider culturally-aware attributes like the formatting for texts, dates, and currencies. As more and more people are gaining access to the internet across the world, that means there are even more and more platforms to test for gauging market readiness.
An example of a situation that could happen in real life I can think of when testing functionality on websites is for international shipping addresses. If a user, we’ll call him Zayn, from London, England is ordering something from a company based in Boston, Massachusetts (USA) and puts in his shipping address, it should not require him to select a “State” under one of the fields after he selects “United Kingdom / England” as his country option. If that field still requires Zayn to select a state when his country location does not have states, there is a problem.
This will change the way I think when I work as when developing code to solve problems or create something new, I will have to think about if the market or target audience goes beyond the USA. When testing the code, of course every possible scenario must be tested already but there will have to be more details to make sure it all goes smoothly–especially since international errors or problems usually take up more effort to fix as communication plays a big factor.
Over the weekend, I had the chance to sit down and listen to another podcast episode by Developer Things. The title, Women in Technology (with Megan Horton), caught my eye as I am always on the lookout to learn about other women’s experiences in technology.
The podcast series’ goal is for people to learn new developer things each time they listen so here’s what I learned on the career side related to software construction, design, and architecture:
- The stigma of “nerds” begins in elementary school so girls start to stray away from STEM even in the limited amount of programs there already are for computer science in earlier education years. This eventually results in the number of females in CS in universities–like mine–is so low along with the numbers of those who move onto the software development workforce.
- There are jobs out there like writing software for watering fields based on whether the sun is up or down or varying weather conditions. It reminded me a bit about how we used duck stimulator as an example to learn UML diagrams and had different actions performed for each duck.
- Career advancement is not always a straight path. People tend to switch into computer science as a major or switch into technology when they want a career change. I’d like to point out how the host of this episode took the opportunity to say Horton came from the funeral business to killing software bugs.
- You won’t always have to write code: there’s so much out there–you could have a passion for anything and do something tech-related in that setting.
The content has caused me to think more deeply about what I will do in technology, I mean of course I’m going with software development or software engineering but what is the overall goal throughout my career timeline going to be? What kinds of companies will I end up working for? What projects or passions will I follow along the way? Overall, I enjoyed the podcast with Horton as she discussed the ups and downs of being a female in technology and her experiences in the industry so far.
I don’t think I was there for the time when people would be kicked off the internet because someone needs to use the phone as discussed in the episode but I do experience times when my connection isn’t consistent. It really makes me sit back and think about how technology relies on constant power and a steady internet connection.
A major takeaway that I continue finding myself writing about is how we will always be learning something new in technology as things are always changing–as long as the power is on.
Imagine being several years into your role as a developer; you’ve had a long week, a big project to push tomorrow and suddenly… you’re stuck on something. And you’ve double-triple-quadruple checked to make sure everything is working by code review but you cannot put your finger on how it is not quite perfect. What’s wrong? Let’s find out.
This is the first course-related podcast I’ve listened to for a blog post and if this is one of the only podcasts you will listen to, I recommend this one.
Jonathan Cutrell started off the podcast by saying “If there’s one thing that makes developers self-conscious it’s probably their googling history–more specifically things that they google that they forgot how to do.”
People can talk about code for days but they do not talk about the toll of what a developer thinks of themself when they are stuck on a part of their code or need to rely on the internet for something. This honesty makes it easier for university students and entry-level developers to understand the pace they are learning at is their own and that not everyone is perfect at coding even after years of experience.
Something that changed the way I thought about this is how important it is to know the pattern or routine of a concept. Things Cutrell says great developers care about is how understanding patterns and principles transfers but not necessarily the actual code itself. “Great developers” focus on the overall concept instead of wasting time on the small details of a language.
Due to this thinking, I realized I never considered how a developer can be the best of the best in one language but if they had to convert it into another language, the translation would be a little different. The real life comparison to this would be if someone were speaking with broken English. This does not mean they are not smart in any way, it’s saying that they are focusing on the main idea instead of a small detail they are trying to get through. They use their time more efficiently by moving on to a big concept instead of worrying about the syntax that they can easily google.
Overall, I appreciate what this article brought up as I was expecting it to be about just googling things but it dug a little deeper and mentioned what a good developer should focus on.
Podcast Episode: https://spec.fm/podcasts/developer-tea/204292
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.