Category Archives: Week 6

Writing Efficient Code

In the second part of Brandon Gregory’s blog post “Coding with Clarity: Part II“, he starts with the assertion that “Good programmers write code that humans can understand”. In the spirit of clarity, Gregory continues to elaborate on solid design principles that are helpful in software engineering.

The first principle is the Law of Demeter, or as Gregory puts it “the principle of least knowledge”, and describes this principle as an application of loose coupling, another design strategy that states one part of a program should not rely on others. Adhering to this principle will help ensure flexibility if new features are added or modified.

An example Gregory uses that demonstrates this principle is the use of getter/setter methods to provide access to class data as opposed to allowing classes to directly access data. By applying this tactic, it ensures that future modifications do not mess up any other parts of your program, as all modifications will be in the getter/setter methods.

The next programming practice is the Interface Segregation Principle. This is to make sure no object contains methods it doesn’t use. If a class has a bunch of methods, and not all methods are used for each instance, the better strategy is to separate that class into specific interfaces or sub classes. This is a similar goal as the strategy design pattern that we discussed in class.

However, Gregory warns us that abstraction can be taken too far. It is possible to abstract so much that the program contains an excessive number of interfaces or sub classes. The author reminds us that the goal of abstraction is to reduce complexity.

The final principle in the article is the open/closed principle. This assertion is that software should be open for extension but closed for modification. If the program is designed correctly, the implementation should perform as specified and should not be modified. Instead, to change functionality of the program, all that should be done is adding functionality, and not changing any of the existing code.

I very much found this two part series of “coding with clarity” helpful.  Almost all of the principles Gregory explains have been applicable to content we have covered in class. I found his writing style easy to follow and the particular examples he uses to demonstrate the principles are cogent and illuminating.  I recommend them to everybody looking to improve their design knowledge.

 

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

Strategies for API Testing

Blogger Lukas Rosenstock posting for the company website BlazeMeter describes common API test strategies and definitions in his post “API Performance Testing Scenarios and Vocabulary“. While a good portion of the post examines how this particular software can help with this type of software testing, the general strategies and explanations he gives are definitely helpful in identifying meaningful test suites.

Rosenstock first describes Application Program Interface or API testing by defining the two main paradigms: Functional tests and Load tests.

Functional tests, aim to verify that the software functions perform as the specifications prescribes. Testing strategies such we learned in class such as equivalence class testing and boundary value testing can help us determine appropriate values to test in order to verify that the program behaves as expected.

Load tests on the other hand, test other real world complications that are out of the scope of functional testing. The main example Rosenstock goes into is the consistency and response time given an expected amount of user traffic. Load tests are generally functional tests that that are performed on many virtual users to simulate when the program performs in the real world.

From here on, the author describes the various types of load tests; what it is they are testing for and strategies for how to collect the information.

First, stress testing is the process of load testing where you start with a small number of virtual users and steadily increase the sample size and record specific performance times. This strategy gives information about performance at specific intervals.

Rosenstock also describes soak tests. The defining qualities of soak testing is to verify that memory efficiency is achieved. If there are any data leaks or unnecessary variables floating around in the software, and the maximum amount of memory is reached, the program can fail. So soak testing is the process of running load tests over a long period of time to determine that space efficiency is achieved.

I found this post helpful in illuminating even more situations that need to be tested for. While verifying the behavior specifications in a program is essential, there are also other real world situations that must be accounted for, such as the volume of user inputs. In this way, load testing is just as essential as functional testing, and this article definitely helped add to my understanding of the scope of good software testing.

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

Testing in Try/Catch Blocks

For today’s blog post, I wanted to cover a specific topic that I don’t particularly enjoy. While that may sound counterintuitive, I feel that it is important to repeatedly work on skills, even if they aren’t your favorite to practice. So for today’s post, I found an article on imalittletester.com about using try/catch blocks in testing. I don’t particularly enjoy try/catch blocks even though they are incredibly useful and necessary. The author explains multiple scenarios that may occur with try/catch blocks, ensuring that false positives are avoided. She dives into the scenarios, using pseudocode to illustrate what a method may look like for each scenario, and examines how tests must be constructed for each scenario to test the proper criteria.

One of her examples, the scenario where a test should only pass if an exception is not thrown is probably my favorite. She explains that the try/catch block isn’t really needed in this scenario because if we are testing that an exception is not thrown, code without a try/catch block would fail just the same as the try/catch block. This is one less scenario that I’ll have to use the dreaded try/catch blocks.

In my opinion, the most confusing of the four scenarios is how to write a try/catch block where a test should only pass if the exception is thrown. The author explains that what must be done to ensure your test works properly is to have a marker in the try block that will execute if and only if the code that is supposed to throw the exception, doesn’t throw the exception. When executing this try/catch block, the only time that this marker will execute, is when your test is failing. The author explains this in a way that is clear, and easy to follow even for those of us who have such a dislike for try/catch blocks.

In all honesty, I’m glad that I chose this article. I try (no pun intended) to avoid using try/catch blocks as much as a I can, as they can be confusing to me at times. But like I said in the beginning of this post, it is extremely important to practice skills and possibly even more important to practice skills that you don’t particularly like. I will definitely consider this article the next time I’m forced to incorporate try/catch blocks in a program I am writing.

Link to the original article: https://imalittletester.com/2017/04/24/better-test-code-principles-5-mind-your-trycatches/

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Testing: Like Destroying Sandcastles

https://joecolantonio.com/testtalks/223-testing-dream-journaling-smashing-sand-castles-with-noemi-ferrera/
In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject.
Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out. 
The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of looking at it, although it is amusing, and I’m sure many developers might harbor some resentment towards testers for telling them their code is flawed.
An interesting side note was something that it sounded like the host said, which was that testing was not in any curriculum that he’s aware of at the college level. He said a lot of computer science majors coming out of college doesn’t know much about testing. I would have thought testing would have been taught more broadly. Perhaps he should take a visit to WSU and audit this class if it truly is not very common. 
She came from humble beginnings, starting to code at nine by fixing bugs in her computer games so they would load faster. Not all of us can say we started coding at such a young age. I was introduced to my first programming class when I was in college. She encouraged listeners to “go to a meet up,” and if there are none around, “make one.” “Be curious and go do stuff,” she said.
I was heartened that she said this because the new chapter of the Worcester State computer science club is holding our first code jam this upcoming Saturday to design out own website. I am excited to do exactly what Noemi is encouraging a beginner coder like myself to do. Although there is probably not going to be as much of a focus on testing at this meet up, I’m sure she would be proud.

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

B5: Unit Testing – JUnit

http://www.discoversdk.com/blog/unit-testing-with-junit

          This week, I found a blog post about Unit Testing, specifically, JUnit. The post began by explaining what Unit Testing is in programming terms and how Junit is a unit testing framework for Java and is tied into Test-Driven Development (TDD). The post explains the features of Junit focusing on how organized and simple it can be compared to other frameworks and testing methods. It specifically compares Junit testing to manual testing showing how tedious manual testing could be. It explains how annotations also work in Junit giving examples such as @Test and @Before while also explaining what they do. It uses real code to show simple tests being completed while also providing and explaining the outputs of each test. The post goes on to talk about the Junit rule which is a principle that works with Aspect Oriented Programming. It essentially means that Junit intercepts the testing method which allows the tester to manipulate things before and after certain test method executions. Junit can also provide a TestRule interface which allows the tester to create their own JUnit Rule for specification and customization.

      I chose this article because I found that I really loved learning about JUnit and wanted more information behind what it can do. I found that this blog post was important as a learning resource for me which made it more interesting to read. I was learning more about JUnit and its many other functionalities in testing which I previously did not know about. The post had a lot of information in it but used coding examples and definitions together to create a flow that read well and was understood much better. I enjoyed how it used these examples with comments and explanation within it to explain what was happening at each line of code. I was able to understand other uses of JUnit, specifically more about the annotations. I found that learning about the @Before and @After was very important to test methods and how they interact with the program while executing. The most interesting part of the post was the part where it explains how JUnit Rules work and how they can be customized using the TestRule interface. I found it very interesting that JUnit allows such customization for rules which makes it flexible as a framework. I thoroughly enjoyed reading this blog post as it did a great job introducing new concepts of JUnit in an understandable fashion while also refreshing the old concepts.

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

The Test Pyramid

For my post this week, I found an excellent blog post by Martin Fowler on his personal website that details the “Test Pyramid.” The test pyramid is a way of representing the proportion of different tests you should be using for the purposes of keeping a balanced portfolio of tests.

test-pyramid

As you can see by the pyramid, user-interface testing is slower and more expensive, moving to service testing which finds itself in the middle and then on towards unit testing which is speedier and less costly. This would imply that in general you want to rely more on unit testing than UI or service based testing, although all of these types of tests have a purpose.

Martin talks about the disadvantages of relying too heavily on user-interface testing. The slow testing increases build times and can require installed licenses for test automation software, which costs money and limits which machine the tests can be run on. The largest con Martin details was how brittle the tests were. That is, any small change to the system could break several tests and require them to be re-recorded. All these reasons show why the pyramid is the way it is, putting UI testing on the higher, smaller end. Fowler makes a point that often the usage of the high-level tests is as a second line of test defense. These tests are able to capture a bug you might have missed or not written tests for, and enables you to write a unit test to ensure the bug is taken care of.

I think the test pyramid is an interesting idea that highlights the importance of unit testing and helps define the priorities we should have as testers. Although it does not dismiss UI or service testing, it clearly demonstrates as testers that we should primarily be using unit testing to fix bugs in the code and make sure they stay fixed. High-level testing can be used to find things that are missed, but shouldn’t be relied on to catch bugs, and they won’t necessarily stay stable when you make changes to your program.

https://martinfowler.com/bliki/TestPyramid.html

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

Factory Design Pattern – Factory Method

In this week’s blog post I decided to share an informative post by Henri Idrovo on dev.to detailing the implementation and usage of the factory design pattern, specifically the “Factory Method.” Henri starts the blog by introducing the problem the factory design pattern is aiming to solve: using the ‘new’ keyword creates dependencies on concrete classes within our program. When many new objects are being created, this tends to get out of hand. Henri introduced the dependency inversion principle, stating “Depend upon abstractions. Do not depend on concrete classes.”

To show how to implement and improve your code using the factory design pattern, an example is introduced that involves a Pizza Store that has to create different types of pizzas. Without the design pattern in place, every type of pizza you would want to make would require another if-statement, so clearly something needs to be fixed. In order to use the factory pattern, we need to separate what is likely to change from what is not, and put what will change in a class of their own.

In Henri’s example everything that is common to pizza creation is placed in an abstract creator class, and the specifics are placed in concrete creator classes that extend the abstract class. Similarly, the different kinds of Pizza are each given their own concrete product class that extends the abstract Pizza class.

The factory method seemed hard to understand at first, but after going through the examples given in the blog it became clear to me, and the advantages of using the factory method are clear. By relying on abstractions instead of concrete classes, you are removing dependencies within your code and making it much more open for modification. Whereas prior to applying the method, the handling of creation of pizza objects was handled within the PizzaStore class itself, it is now handled within concrete sub-classes that can also handle different categories of pizzas. Also, personally it is easier to read the code of the PizzaStore class after applying the factory method, and it is much more clean in the abstraction. I can see the factory method being useful in any situation where you have to deal with the creation of a lot of categorically related but different objects.

https://dev.to/henriguy/design-patterns-factory-pattern-part-1-6k0

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

How to Write Better Unit Tests

Today I will be talking about a blog called “Unit Testing, How to Write Testable Code and Why it Matters”. This blog talks about the importance of unit testing for anyone who is a software developer. The blog talks about what unit testing is, what it consists of, and something that I had never heard of until today; the three A’s of unit testing:  Arrange, Act, Assert. We will talk about these three A’s of unit testing in more detail later. Another thing the blog talks about is unit testing vs integration testing. The blog sums up the difference between the two as unit tests have a narrow scope to test just one small part of the program whereas integration tests test how the “pieces” of code fit together and work hand in hand. Essentially, integration testing is a larger scale version of unit testing. So what exactly makes a good unit test? According to the blog, good unit tests consist of tests that are easy to write, readable, reliable, fast, and truly unit testing (not integration testing). This is where the three A’s of unit testing come into play. After you make sure that your unit tests adhere to the rules of good  unit testing, you can apply the three A’s of unit testing. The three A’s (as mentioned before) are Arrange, Act, and Assert. Firstly, we arrange. We do this by testing small portions of the code (unit tests) to ensure they work as designed. Next we give the test some sort of input to “test” its function to make sure it works correctly, this is also known as the Act phase. Lastly, we Assert what we know our output should be and we then compare it to the output of the function we are testing.

I think this is an extremely important article because it has given me a lot of insight on how to make good unit tests and how to make the testing cycle easier by remembering the three A’s of unit testing; Arrange, Act, Assert. I hope to use the three A’s of unit testing in my future programs in hopes that my testing will go smoothly and quickly. Another thing the article talked about that cleared up some confusion for me is unit testing versus integration testing. For me, the two have always been kind of interchanged and intermingled, as they are very closely related. I think that many people know there is a difference between the two, but do not know exactly what that difference is. It is good to think of it as integration tests being larger scale unit tests. In my head, I now think of integration tests as being made up of smaller unit tests, and seeing how those unit tests work together. I think this article was overall a really good read and will make my approach to writing tests for my programs change for the better.

Here’s The Link: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

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.

More About Test-Driven Development

In my last blog post, I briefly mentioned the idea of Test-Driven Development (TDD) as a process for creating programs, as well as its tying-in to Behavior-Driven Development (BDD). I wanted to learn more about TDD, so that will be the topic of this post! The article that I chose to read came from the following website: https://www.stickyminds.com/article/value-test-driven-development-when-writing-changeable-code.

This article touched upon concepts presented in both of the software development courses that I am taking (Software Design, Construction, and Architecture; Software QA and Testing). It highlighted the importance of making code that is easily changeable using techniques such as abstraction, encapsulation, or various design patterns. With this kind of coding strategy, developers don’t have to be as concerned about the whole program being affected when a few lines of code are revised. This is associated with more of the software design side of TDD. However, the process by which TDD takes place focuses on software testing, where further code is not written unless the automated and continuous tests produce a failing result. These tests are also written independently of the code being implemented. In other words, the code being tested is considered to be black-box, and the tests are made to uncover the failures in code, from which revisions will be made. This is where changeable code comes into play. This kind of coding mentality strives to ensure that the entire functioning of the program won’t break when the code is changed. This includes the automation of TDD; when the entire program is being rewritten because of a lack of changeable code, this may have additional effects on the testing process.

However, the article is quick to note that while TDD is a way to specify code behaviors by continuously testing and fixing code, it does not replace the process of Quality Assurance. With QA, the potential for code and tests to go wrong, as well as possible ways to navigate around these problems, are all considered. TDD is more “implementation-independent,” where the tests being run are not to assess the way behaviors are implemented in code, but in a more general sense, to simply express the behaviors that the program aims to implement. TDD, in a way, shows the specifications of a given program, and with continuous testing, can exploit the holes in a program so that they can be further improved.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

The Four Levels of Software Testing

This week’s blog is about the four levels of software testing.  There are four main levels of testing that needs to be done before a program is ready for use: unit testing, integration testing, system testing, and acceptance testing.

Unit Testing

Unit testing is the first round of testing. In Unit Testing, the program is assessed with the focus on specific units or components of the software to determine whether each of them is working correctly. A unit can be referred to as a function, an individual program or even a procedure. The white-box testing method is usually used to do this kind of job since it is based on the analysis of the internal structure of the system or component.

Integration Testing

Integration testing, on the other hand, allows you to combine all of the units within a program and can be tested as a group. It is designed to find interface defects between modules or functions. It is very useful because it measures how efficiently the units are running together.

System Testing

System testing is the test ran after the application is actually completed and tested. The goal of this test is to check whether the system met all the requirements and see if it meets the Quality Standards. This test is done by testers that were not part of the development team. It is performed in an environment that’s somewhat the same as production. System testing verifies that the application meets the technical, functional, and business requirements that were set by the customers.

Acceptance Testing

Acceptance testing is the final test. This test basically determines if the application is ready to be released. During this phase, the users test the systems to find out if the application meets the business’ needs. Once this is completed, the application is ready to be delivered to production.

I find this blog interesting because at first, it looks like a really simple process to create an application and put it out on production but there are actually different levels to it. This has changed the way I think about software development. Just thinking about the process of testing the application, I could already see it having a great importance in software development. Also, you could be moving back and forth on the different levels of testing when the specification changes.

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