Category Archives: CS@Worcester

Detecting fake news at its source

http://news.mit.edu/2018/mit-csail-machine-learning-system-detects-fake-news-from-source-1004

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 mediabiasfactcheck.com, 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: https://completedeveloperpodcast.com/episode-140/, 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.

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.

factory design pattern

This week blog post is going to be about one of the creational design patterns, Factory Pattern. Factory pattern has many advantages:

  1. “Factory design pattern provides approach to code for interface rather than implementation.
  2. “Factory design pattern removes the instantiation of actual implementation classes from client code. Factory pattern makes our code more robust, less coupled and easy to extend. For example, we can easily change PC class implementation because client program is unaware of this.
  3. “Factory pattern provides abstraction between implementation and client classes through inheritance.

When we have a super class, which can be an (interface, abstract class, and concrete class) with many sub classes and we want to return one of the subclasses based on a specific input, this can be done with Factory Design. The benefit of factory design is that we don’t have to instantiate a class every time we want to use a class instead we can just call the Factory class.

For example, if we had an interface named Game System and we created more than one sub class that implements it (ps4, Xbox, and pc) and then we wanted to use one of those objects in a test class, we would have instantiated one of the sub class every time we created an object from the class. This way is very tedious, that’s why Factory design is so helpful. Instead creating a object every time, we can create an Game system factory which allows us to input for example enter a string name “ps4” and create a ps4 class instead creating for example GameSystem gs = new ps4(); every time.

I think factory design pattern should be used mostly every time if there are more than one sub classes just because it removes clutter and simplify the code to be more readable. From my personally experience I think factory design patter help me think more about organization when coding. I always think of ways to make my code more reusable after reading this article. All in all, Factory design pattern is very helpful and is an important method when it comes to Object oriented programming.

https://www.journaldev.com/1392/factory-design-pattern-in-java

From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.