Category Archives: Week-2

Thanks for Coming to My Test Talk™

CS SERIES (3)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.


Article: https://techbeacon.com/7-habits-highly-effective-sdets

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Value of Unit Testing

When you ask a group of developers what is more important, writing adaptable code or writing tests for the code to pass? I believe that both are equally as important as the other. I came across a blog by Tobias Goeschel, “Writing better tests with JUnit”, where he talks about the importance of writing better tests. In order to keep your code as high quality as possible, you must write tests. Poorly written tests as he describes may lead to bugs bypassing your code and having malfunctions in your program. As he lists in his blog, a set of well written tests will tell you (and more):

  • How to access the API
  • What data is supposed to go in/out
  • What possible variations of an expected behavior exist
  • The exceptions that might occur
  • How parts of the system interact with others

Tobias goes on and talks about how good tests should not be underestimated because it not only helps new team members understand what should be done but also reviewing old code that’s to be tampered with.

Reading through this article it all makes sense why we were always so test driven with the projects that we did in Data Structures. Every project we wrote had to pass a certain amount of pre-written tests. The author stressed the importance of unit testing which changes the way I will write in the future. Not only will I focus on written code but also tests. I believe that Unit Testing is equally important as mentioned.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

B2: Static vs. Dynamic Testing

https://www.360logica.com/blog/difference-between-static-testing-and-dynamic-testing/

            While trying to gain more information on Static and Dynamic Testing, I found an interesting blog post that pit the two against each other. It started by explaining that Static Testing is used to test things related to the actual code within a product. The post further says that Static testing is where developers check code to find faults. This testing can be completed without any current applications. The post then defines Dynamic Testing as testing the application with valid entries and checking their outcomes against an expected result. After explaining the two terms, it stated the major differences between them like how Static testing is a preventative measure while dynamic testing is used in solutions. The post explains that Static testing is therefore more cost-effective and provide greater benefits when compared to Dynamic testing. Dynamic testing can take longer as it tests each case separately while Static testing can cover more in a shorter amount of time. The blog post goes on to explain that since Static testing is done in a verification stage, the code can be looked at without any execution. This differs from the Dynamic testing which is done in a validation stage where the code is executed and tested without being looked at.

            I chose this article because I found myself interested in the difference between Static and Dynamic Testing. I understood these terms in a programming sense, but I didn’t quite grasp the concept in a testing setting. My initial curiosity was filled with a sense of what these different testing types meant. I found the post very informative on what each testing type did and how they worked. I can understand that Static testing is better overall because of its speed and benefits but I also understood how Dynamic testing works as well. I enjoyed how the post used multiple examples when explaining these terms because it allowed me to get a better understanding as to the context of the definition. This blog post has taught me that Static testing is the go to style for testing as it is cost-effective and overall better. The most interesting part about this post was the different benefits it stated between Static and Dynamic testing as it gave a better insight to how they both worked.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Understanding Cohesion

Cohesion is one o the most important concepts o Software design, and it’s used as a measurable factor in how strongly are software’s features related and how software’s pattern is consolidated as one frame. Modern software design strategies suggest to use cohesion as a slide ding scale instead of binary attribute as it was introduced in 1974. As … Continue reading Understanding Cohesion

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Tips on writing a better test in JUnit

Writing Better Tests With JUnit by Tobias Goeschel

For this week’s blog, I chose “Writing Better Tests With JUnit” by Tobias Goeschel. The blog contains different tips and suggestions on how to write a better test in JUnit. It also emphasized the idea that having a readable test code is at least as important as writing a readable production code and that the focus of the test must be on behavior instead of implementation. Another tip was to group tests by context. Grouping the tests by context would help us organize and focus on behaviors that should be grouped together. It would also help to understand the behavior more quickly and easily.  Tobias also talked about enforcing the Single Assertion Rule. The rule was to use a single assertion if possible, but not it does necessarily mean that there could only be one assertion called, there are times when you would want to have multiple assertions. He also emphasized choosing meaningful names for the tests, it would be easier to know what the test is testing and eliminate unnecessary comments. The blog also talked about using other dependency injection frameworks like Spring to keep the tests fast and to avoid overly complex configurations. Lastly, he talked about avoiding test inheritance if possible since navigating the class hierarchy to get an idea of what is happening would make the test harder to understand.

I really find this blog useful. It stresses the idea of test behavior, not implementation. The blog also has some code in it where you can see how the tests are implemented. There are also different patterns that are useful when testing in the blog like the “Triple A” pattern which stands for “Arrange(preconditions and inputs)  Act(things happen, methods are tested)  Assert(see if the result was right)”.  The other thing that I thought was thought-provoking is the use of inheritance. He said that it should be avoided if possible but when I read his explanation, it makes so much sense not to use inheritance. The way he emphasized that tests are as important as production code changes the way I think about coding now. I feel like writing test cases before writing the actual code might be a better approach to writing software.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

if (two < one) {

CS SERIES (2)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.


Article: https://www.codesimplicity.com/post/two-is-too-many/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Is your code actually yours?

While sifting through blogs trying to determine which might be a good read, there was one in particular that caught my eye. We all know as developers we love to start new side projects and never see it to completion am I right? Well that’s true in my case anyway. As I read through Joel Spolsky’s article, “Developers’ side projects”, I learned some fascinating news that I shall keep in mind for the near future.

In the opening paragraph Joel talks about some kind of proprietary invention agreement that most developers sign when working for an employer. Basically what this agreement states is that whatever the developer comes up with or invents while employed by said company will belong to said company. Yes that may seem silly but to the company it is very profitable. Say you are the employer and one of your developers create an app that gets 1 billion users over night. You would want the rights to this app to maximize all profits. Smart.

This article was very interesting because it opens your eyes as a young developer waiting to join the real world. Never did I ever think that once I would be employed as a developer that a company MAY have the rights to the work that I do in my spare time. Spolsky talks about legality issues that might come about if you were to create a product while employed under a company and what could happen if you try to branch away to form your own competitive company. He then states that the only way for independence is to be independent.

Many questions come to mind after reading this article. Should I be afraid to create content once employed? Does every employer attempt to own the rights to every employees’ work? For one, I do agree that there is ease of mind working independently but sometimes that’s not always the best case. Moving forward I will make sure to read contracts thoroughly before I sign anything!

Don’t forget to share and follow 🙂

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Round Earth Test Strategy

This article is very interesting in that it offers a new perspective on the importance of a front-end user perspective first type of testing scheme. It starts off by explaining to us the normal pyramid testing scheme and how at the tip of the pyramid is where the user perspective and UI is. This article is contrary to all of those other testing pyramids because, by how this article explains it, the top of the pyramid is just as, if not MORE important than the lower levels. Typically in a Test Automation Pyramid you have Unit or unit tests at the bottom (long base), then you have your service tests (integration, component, and api tests: middle slice), and finally at the top you have your user interface and ideally what the user sees. Knowing that, this article explains how the pyramid should actually be flipped upside-down, having the user perspective be of larger importance. You would still have your unit tests and integration on the bottom and middle, it just wouldn’t be as large. This is the point the article is trying to make, “Just as a triangle has more area in its lower part than its upper part, so you should make more automated tests on lower levels than higher levels.” This is not an argument; this is not reasoning. Nothing in the nature of a triangle tells us how it relates to technology problems. It’s simply a shape that matches an assertion that the authors wanted to make. It’s semiotics with weak semantics.” Pretty much, the article is saying that the shape of the triangle in which these schemes are based on don’t really carry that much weight into technological problems.

My reaction to this article is that I agree with what they are describing here. Similarly to the article, I also think that when you have a project, each layer above the next can often be a lot more complex than compared to the lower levels. This in turn can also even carry a higher risk. The model the author is talking about is the Round Earth model. The round Earth model states that you should think of technology as concentric spheres and that each layer can increase dramatically. This article made me open my eyes and made a lot more sense of how certain models don’t really understand what they even stand for.

 

 

From the blog CS@Worcester – Amir Adelinia&#039;s Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

JUnit Best Practices

For this week, I read an article called “JUnit Best Practices” by Kyle Blaney. The article talks about how to use JUnit in the most efficient way and get the most out of the tests. The two main goals of unit testing according to the article are making sure tests are “extremely fast” and “extremely reliable”, meaning your tests should run as fast as possible while also producing correct, reliable results. The article then goes on to point out a number of different important practices when doing unit tests. Some of these practices are ensuring unit tests are running completely in-memory (tests should not read from the filesystem), not skipping unit tests, aiming to have each test only test one thing, using strong assertions, and much more.

I thought the article was extremely informational and very useful. We will be looking at unit testing in CS 443 this semester and having this information should help me produce better unit tests, whether they be self-written or just by using JUnit in the most efficient ways possible. I found it useful that the article mentioned doing things such as using the strongest assertions possible and making sure your tests are reliable. Having strong assertions will mean that if the unit test passes your assertion, then your code should hold up in the long run. However, none of this matters if your tests are not reliable and do not produce correct results. So making sure your tests are reliable is a huge part of the testing process. With the combination of correct, fast tests and strong assertions, your unit tests should be very strong. I like this idea of having strong unit tests because if my code can get through the strongest, hardest tests then my code should be very strong overall.

I agree with all the points made in the article, and I hope to use the information presented to me in the article in the future when I go to do unit testing. I would like to see how applicable these practices are in real life testing and see if they all hold up like they are supposed to. I am looking forward to unit testing because I now know some very important aspects to look out for.

Here’s the link: http://www.kyleblaney.com/junit-best-practices/

 

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Shailesh Rao on Quality Assurance

In this episode (number 219) of “Test Talks,” I was able to hear Shailesh Rao’s insight into having quality software. He compared it to a “paper-free office” or a “stress-free life,” both worthy goals, but are hard to achieve. They can be strived towards, but it is near impossible to get it 100%.

He brought up the issues that bad software can pose to potentially millions of users. Bad software can open the doors to hackers, who might be able to take down websites like Twitter or Reddit. Also, it might stop airlines from being able to function — an annoyance to most, but Mr. Rao asked, “what if there was time-sensitive and lifesaving medicine onboard?”

I found this podcast brought up some aspects that I had not thought of before when if comes to quality assurance. I suppose that I’ve thought about the various things he brought up, but as a consumer and never as a creator of the software.

A very thought-provoking topic brought up was the fickleness of consumers. They don’t have the patience to put up with a buggy app. They will move on to the next thing. It is easier than ever to launch a software project to a very wide audience, and it’s become apparent to me that it should be done right the first time around because customers don’t always give a product that flopped a second chance.

Another point brought up that will affect the way I think about testing and quality control is that you should test for all possibilities or you might not know the market you missed. People often say to themselves “it won’t happen to me,” and think their software will not be downloaded millions of times, but if they didn’t prepare for those conditions, they won’t get that chance.

The core message that was hammered home was that developers should have quality at every step. With as complicated software can be, it is extremely difficult to have it be truly bug-free, but it is possible, and we should always strive to be as close to it as we can.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.