Today blog is about Black Box Testing vs White Box Testing. First, Black Box Testing is when we’re testing if a system is functional or non-functional without knowing the internal structure (code). There’re many techniques that can be used for designing black box tests like Equivalence Partitioning, Boundary Value Analysis, and Cause-Effect Graphing. All these techniques are similar as they all are testing input values with valid output values. There are also many advantages with Black Box Testing. First, the tester doesn’t really have to be a programmer or need to know how the program is implemented. Second, the test is using done more hands-on and with user’s point of view which allows reviews of the product to be more unique in a way that every tester/user have a different opinion on the product. There are also disadvantages for Black Box testing. First, there are not a lot of many inputs that can be tested which means there is still many of the area of the product that are left untested. Second, without the specifications the test cases are difficult to design. Also, testes can be redundant because of the lack of test. An example I think is good for Black Box testing like tester testing an app by using it and checking if every action works as it should.

White Box testing is when you have full access to the information of the product and test the internal design. It tests the input of the test’s cases with the expected output.  A great example of White Box Testing is “like the work of a mechanic who examines the engine to see why the car is not moving”. White Box testing is usually applied to unit testing, but I think it’s the most effective method because you have all the specifications and most all part of the product will be cover. The disadvantages are that it requires skilled developers because some tests are complex.

All in all, both Black Box testing and White Box testing are both effective in their own way. Black Box testing is mainly for Acceptance testing and White Box testing is for unit testing. I like White box testing more because I full access to the code which means I can better understand the mechanics of the system.

http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing/

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

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.

This blog is about Static testing vs dynamic testing. Static testing is when the code is not executed. It’s when we manually check the code, requirements, and design to find errors. The main objective of static testing is to find errors in the early stage of the development cycle to improve the product. Dynamic testing in the other hand is when the code is being executed. Its testes the software system, memory/cpu usage, and the overall performance of the system. The main objective for dynamic testing is to confirm if the overall of the product, perform as expected by validating the output with the expected result. This can be done with black and white box testing because either method just requires comparison with the actual and expected value.

I think both testing methods are both useful. Static testing is for more for early stages of the software projects in my opinion after reading this article because it seems like this method revises the code and   making comments and documenting errors and potential problems.  This is useful because it allows to transition to dynamic testing later when we get to execute the actual program and there’s less errors and more problems that we aware of because of static testing, if we are using both methods to test a software.

I now like static testing a lot more now after reading this article because we get to review the design and the requirements which will make the product better. Making changes early and finding defect will save on cost. Making sure the everything is clean before the actual work is my ideal testing because it saves time and headaches when actual implementing the program when finding errors.

I think dynamic testing is more straight forward because you are really testing the actual output with the expected output and find the error if the two output don’t match. Doing this for every module is having them all pass assure that the product is completely running as expected. This method is used more by me because I think it’s a lot quicker to run the program and find the error if outputs don’t match and fix it but after reading readings this article I am assure I will be doing both for my future projects because static testing will save time. I think of it as if I static is writing pseudo code and dynamic is coding. In conclusion, both are useful methods and are used to improve a software product.

https://www.guru99.com/static-dynamic-testing.html

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

This week blog post is about Java Singleton design pattern. The reasons for Singleton pattern are to restricts the instantiation of a class and ensures that only one instance of the class exists. This article explains and show examples of the many different approaches of Singleton pattern implementation, the problems with the approach.

The approaches of Singleton pattern implementation:

1. Eager initialization – pros: easiest way to create a singleton class | cons: instance variable is created even though it might not be used.
2. Static block initialization – Similar to eager initialization but provides option for exception handling.
3. Lazy initialization – This is the approach that was we used in class and it’s a completely fine for a single threaded environment, but potential can cause problems for a multi-threaded environment.
4. Thread Safe Singleton – resolutions for Lazy initialization but reduces performance. Requires synchronization.
5. Bill Pugh Singleton implementation – Best method for singleton implementation. Contains a inner static helper class by doing so the instance is not created unless someone calls on the getInstance() method. Doesn’t require synchronization.
6. Using Reflection to destroy Singleton Pattern – This approach destroyed the singleton pattern.
7. Enum Singleton – resolution for reflection method. Not flexible. Any enum value is instantiated only once.
8. Serialization and Singleton – Use to store it in file system to retrieve it later. Cons: when deserialize it creates a new instance of the class.

I found this article very helpful with understanding Singleton design. This article explains to me when to use and the consequences that comes with each different implementation. The content of this blog was the best. The example code of this article was very clear and made easier to understand the materials. This change my way of using this method because I now know which method to choose in certain situation. The lazy initialization will be used more while I’m in school, but I think Bill Pugh method will be used more in the future because it’s very popular and it’s easy to understand. I agree with all the contents, but I read the comments of the other readers and they had some issue with some of the content which I have to read more about the subject to find out what’s right and wrong.

https://www.journaldev.com/1377/java-singleton-design-pattern-best-practices-examples

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

Hi my name is Quoc Phan and this is my blog for CS 443. I will be consistently posting interesting stuff that I’m learning throughout this course.

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

Hi my name is Quoc Phan and welcome to my new blog where I post all kinds of cool and interesting things that I’m learning.

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