Category Archives: CS-443

Detecting fake news at its source

This is an interesting article about how researchers are trying to make a program that will decide wether or not a news soucre is reliable. This program uses machine learning and scrapes data about a site to makes its determination and it only needs about 150 articles to reliably detect if a source is accurate or not. Researchers first took data from, a site that has human fact checkers that analyze the accuracy of over 2,000 news sites. They then fed that data into their algorithm to teach it how to classify news sites into high, medium or low levels of factuality. As of now, the system was 65 percent accurate at detecting these levels of factuality and 70 percent accurate at deciding if a source is left-leaning, right-leaning or moderate. The researchers determined that the best way to detect fake news were to look at the language used in a sources stories. Fake news sources were likely to use language that is hyperbolic, subjective and emotional. This system was also able to read wikipedia pages on sources that were fake news and noticed that those wikipidia pages contained an abnormal amount of words like extreme or conspiracy theory, even making correlations with the strcuture of a sources URL, sources with lots of special characters and complicated subdirectories were associated with being less reliable.

I think this is noteworthy because of how important accurate information is on the internet. There are a large number of people that spread misinformation on social media and influence the behaviors and thoughts of their readers. There are constantly news stories on bots from Russia or other countries trying to spread misinformation to not only the United States but anyone they consider a threat. The spreading of this fake news can cause a lot of problems and pose a serious issue for the information age to the point that I have heard people refer to our current time as the “misinformation age”. If automated software is able to detect fake news at a near perfect accuracy it will help the entire planet in combating such a large and seemingly unbeatable problem. Something that takes hundreds of fact checkers could take a program a few minutes and it could be accesible to the general public for all of thier needs. Although the algorithm in its current for is not accurate enough, it is a step forward and a look at a possible solution that we desperately need.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

Journey into Unit Testing with Test Driven Development

As I take my first step towards my journey in Software Quality Assurance and Testing I dive into Unit Testing. After searching the web found a really good podcast named “Unit Testing With Test Driven Development” by Beej Burns this podcast is about Unit Testing and focuses most on Test-Driven Development (TDD). I will be using this podcast to help me write this blog.

In the podcast they had two guess John and Clayton. They went on the podcast and talked about their book ‘Practical Test-Driven Development Using C# 7: Unleash the power of TDD by implementing real world example under .NET environment and JavaScript’. I personally have not read this book. According to the podcast this book is meant for Software Developers with a basic knowledge of TDD. This book is intended for those who wish to understand the benefit of TDD. This book is beneficial for individual who know C# basic since all the examples are in C#.

The Following Q&A are the Question asked in the podcast and the guest answer. The answer I am writing are summarized in my own words but originally derived from the guest on the podcast. Also I am not doing all the Q&A just the ones I found interesting and liked how the guest answer the question. If you want to hear the original question and answer visit the podcast site:, Lets start.

What is Unit Testing?

Unit Testing is the ability to test in isolation. That is to simply test an application without affecting the rest of the other test.

Why is Unit Testing important?

We use unit testing to make sure each unit performs as intended. Unit testing is important because it minimizes the risk of error in your software, but it also forces you to have better code structure. It also allows major changes in your code to happen at a lower risk. Another reason it is important is because it allows new developer to understand your software structure.

*Note that naming convention is very important so developers can understand what is being tested.*

What is the point of Test-Driven Development (TDD)?

The point of TDD is doing the right thing without making a mess. That is short iteration cycle reassuring that you and your application are doing the right thing.

According to one of the guests when writing Test-Driven Development there are 3 stages/steps:

  • Red cycle to see test fail
  • Green phase when you make the test pass
  • Refactor production code and test code.

The idea of TDD is to build the test before the code.

Other benefit for TDD other than code in an organized level is:

  • Reduces the overall bugs and make bug resolution quicker.
  • Less down time.
  • Better requirement
  • Can find problems with just running the test which it shows where code went wrong.

What are some of the things people get wrong about unit testing and TDD?

Testing your test too close to your implementation. “Test should represent the business rules not how you decided to implement the business rule. That way when you go and change stuff later on like the implementation. You want to refactor and remove thing into a different class. This doesn’t break what your test does because you will be restructuring how it is doing it”.

How do you manage complexity on a unit test, and how do you structure your overall testing projects?

“Form an overall method uncle bob (Robert Martin) suggest only having method that are five lines or less in size”. The guest that answer this question take Robert Martin suggestion to heart. He goes on and explains that if a method has more then five lines then he’ll brake it down into more than one method. If a class has more than five method then he’ll brake that down into more than one class. If a folder has more then five class than he’ll brake that down into more than one folder. If a project has more then five folder he’ll consider braking it down into more than one project. He goes on and say that he will do the same exact thing when testing except he doesn’t care much about the line length because most test case are usually 3-4 lines long. He has the arrangement where he set up the pre-content of the test and then have the action are 1-2 lines. These tests are pretty small to start with but within a test class he won’t have more than five things overall that he is testing within a test class, no more then five unit, and no more than five logical assertion which tends to reduces the size of any one thing within a test project.

What are some good practices you can use to make sure your test is maintainable on the long run?

  • “Don’t forget to refactor your test, because your test suit is just as important as your production code”.
  • “Remember you are testing small unit or small pieces that should have never enter connective dependency so that you feel comfortable substituting a mock, spy, or fake implementation. Be careful not to test your fake, mock, or spy.”
  • “Where ever the code end that’s where the test should end”.
  • “Make sure we abstract all third-party code”.


I will wrap this up by saying unit testing is a very important skill to have no matter what. It helps in creating clean code and reduces the risk of error. Unit testing allows software developers to make large changes in the software code at a minimal risk rate and it allows code structure to be understandable by new developers. One thing to note is when creating unit test and developing software you must make sure to have good naming convention. When developing software, its best to start with writing the test first.

My name is Yesenia Mercedes-Nunez and this has been YessyMer in the World Of Computer Science, thank you for your time until next time.




From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes 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 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:

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
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

          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.


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.

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:

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:

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.