For this week’s blog post I will be taking a look at another antipattern, another very common AntiPattern that creates maintenance nightmares. It usually takes the form of several similar segments of code that are interspersed throughout the software project. Programmers who are learning how to develop software who are following the examples of more experienced developers usually fall prey to this unwillingly. They do this by modifying code that has worked for them before in a similar situation and they think by potentially customizing it to support new data types they can get by but this causes code duplication which may cause positive outcomes but long-term problems. Symptoms of this antipattern include the same software bug that reoccurs throughout the software despite local fixes, lines of code increasing but overall productivity not being affected. Essentially this antipattern re-uses code that you may or may not need adding to your lines of code without any actual assistance being provided from the length. The most common cause of this is a lack of abstraction among developers who are often accompanied by a poor understanding of inheritance, composition, and other development strategies. And is most likely to occur when people are unfamiliar with new technology or tools as a result, they take a working example of something and modify it, trying to adapt it to their specific needs. Some solutions to this involve white box reuse through the developers extending systems primarily though inheritance. On the other hand of this black box reuse has other advantages such as the object is used as-is, through a specified interface where the client is not allowed to alter how the object interface is implemented. In a way this antipattern is very similar to spaghetti code but spaghetti code is not structure for easy component reuse because of this Cut and Paste Programming is the only means available for reusing preexisting lines of code.

https://sourcemaking.com/antipatterns/cut-and-paste-programming

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

For this weeks blog post I will be looking at an Antipattern known as Spaghetti Code from Source Makings site. Perhaps the most famous AntiPattern it has existed in one form or another since the advent of monogramming languages. Essentially Spaghetti Code is a very cluttered or messy design approach causing it to appear almost like spaghetti, all tangled up.

Nonobject oriented languages appear to be more susceptible to this, and this is more likely to occur to those who have yet to fully master advanced concepts involving object orientation. The general form of this spaghetti code appears in systems with very little software structure. “If developed using an object-oriented language the software may include a small number of objects that contain methods with very large implementations that invoke a single, multistage process flow. “.  On top of this object methods are invoked in a very predictable manner, with a negligible degree of dynamic interaction between any of the objects involved in the system. Causing the system to be very difficult to maintain or extend, allowing no opportunity to reuse the objects and modules in other similar systems. Spaghetti Code usually results in an inexperience with object oriented design technologies, similar to this no design prior to the implementation of the actual code. Another cause would be the result of developers working in isolation because of this their maybe ineffective code reviews.

A solution to this not so delicious mess would be through software refractoring (code clean up). This being an essential part of software development, allowing most efficient clean up. When the structure becomes “compromised” through the mess its support to extensions become more and more limited to the point of useless. Ideally code cleanup should be happening throughout the entire development process but that’s an ideal situation that not everyone (including myself) follow all the time. Doing so on an hourly or daily basis is a good start to this cleanup process.

If simple code clean up is not working what next? Stopping spaghetti code through prevention is usually the best way to resolve this matter. Before you start writing the code, have a plan of what you are designing and how to structure it. Commit to actively refractoring and improving spaghetti code whenever the code needs to be modified is an extremely useful to prevent it.

Essentially if you don’t want to have spaghetti and meatball code you need to think about the overall structure and a good idea of what you are going to be developing.

https://sourcemaking.com/antipatterns/spaghetti-code

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

For this week’s blog post I found a blog that shows you how to reproduce a bug in your application. Why is this important? Well if you see something wrong in your application but cannot reproduce it this blog may help you with it. An obvious but important step to undertake is to simply gather information, and as much of it’s you possible can about the circumstances of the issue you are looking for.  Retracing the steps just before the bug appeared is a good way to do this the same goes if someone else reports the bug. Pertaining to another person reporting the bug is it a different operating system their using? A different browser or a different browser version? Again, obvious questions to some but to others they might not think about it. Keeping track of what changes, you have made trying to reproduce the bug is very important, knowing what you’ve tried and haven’t is crucial. I know this is something I would probably not keep track of which would cause me a lot of frustration. Going off of this using logs and developer tools are extremely helpful in providing a sense of direction in the behind the scenes of the application. If using a browser, especially chrome, you can simply go to the top right and find all the developer tools by clicking the three-dot menu. The blog then lists numerous factors to consider when trying to reproduce a bug, here I will discuss a few. Going back to the user end of bug, did the user not have the correct permission or a specific permission level? If so, you may be dealing with a bug that is only seen on an administrator level or by a certain type of customer. Authentication may be something to take into factor if the user cannot log or such. what is the state of the data that the user has? Can you reproduce the state exactly? The bug may only appear when a user has a very long last name or a particular type of image file. Another simple factor is configuration-based issues. Something in the application may not be set up properly. For example, a user who isn’t getting an email notification might not be getting it due to email functionality being turned of for their account. Checking all of the configurable settings in the application and trying to reproduce the issue with exactly the same configuration is the best way to check for this. Another issue some may not think about are the race conditions. The best way to determine if there is a race condition is to run your tests several times and document the inconsistent behavior. Clicking on buttons or links before a page has loaded in order to speed the input up or throttling the internet connection to slow the input down are good ideas for this. The last one they list is a simple machine or device based issue. This is probably the most common one that we face in all honestly, we’ve come across it a few times this semester even between Mac and Windows. Essentially something is working on Mac then is transferred over to a Windows device and does not work since it was originally made for a Mac and didn’t consider something small that windows does not have and more. After reproducing the bug you want to narrow the steps down to make it as efficient as possible making it easier for either you or the developer to fix in the code in the future.

All and all I thought this blog was actually pretty helpful at explaining steps on how to reproduce bugs and to help find them and make your testing process a bit smoother..

http://thethinkingtester.blogspot.com/2018/12/how-to-reproduce-bug.html

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

Angular Unit Testing

For this week’s blog post I thought I would take a look at Angular Testing considering in class we have been discussing it and are going to use it for our final project. From the site I found they go into great detail as why it is good to use angular and overall how to conduct it properly. They first start off by listing an example of code that complies properly and “works” but under a more complex situation with dozens of tests in a suite it may begin to fall apart. They go on to explain that for every run it will recompile the components and operations taking up to 75% of your time recompiling and not actually running the tests themselves. Next, they show an Angular Testbed monkey patch that will patch the testing framework resetting the testing module before each run and each test. The TestBed.resetTestingModule function they use will clean up all the overrides, modules, module factories and disposes all active fixtures as well, essentially cleaning up what you have. A _initIfNeeded function then comes into play , preserving the factories from the previous run doing what they need to do. If the flag is false the TestBed function will re-create components required for the test, creating a new zone and testing module but not recompiling anything if moduleFactory is in its correct place. After this they run the code they have, clocking in at a 24 second run time to complete its test suite. Then they apply the patch by calling a setupTestSuite function and replacing beforeEach with beforeAll causing the run time to become 8 seconds. A notice 3x time increase in time efficiency for this certain example. With this patch it allows them to preserve the compliation results and re-use them for multiple test per suite.

After this they start up Karma parallel tests, allowing for the tests to be run in parallel. This website shows all the code which is quite lengthy and I wouldn’t want to subject you all to a blog post that takes up too much space. By clicking the link below you can see all the code they have and more. All and all this website was pretty handy and interesting with what they described and how to show angular to its potential.

https://blog.angularindepth.com/angular-unit-testing-performance-34363b7345ba

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

For this week’s blogpost I will be looking at yet another design pattern called the Prototype Design Pattern. Creating objects can take a lot of time and can be an expensive affair so in order to save time and money we can dive into cloning to solve this problem. You would want to use this pattern when the cost of the object to complex or expensive. After all, the clones in Star Wars were made to be cheap and expendable ultimately, the same goes for the idea behind the cloning pattern. Trying to keep the number of classes at a minimum is also a great time to use this object. Another big reason to use this pattern is when the client is creating objects that are required which are very similar to already existing objects, hence cloning. Essentially what this pattern allows you to do is make new instances by creating copies of existing instances. The result is a cloned object which is different from the original object, causing the state of the original to be the same as the clone right after the time of cloning. Therefore each object may undergo some state change, modifying the objects to perform different things after this is easily done. The structure of this pattern comes when the prototype class declares an interface for cloning itself by implementing the clone able interface and using the clone() method. Concrete Prototype then implements the clone method for cloning itself. After this the client class creates a new object asking the prototype to clone itself rather than using a new keyword. You need to instantiate the original class A(the class you are cloning) before using it. Then the client requests the prototype class for a new object of the same type as class A. This patterns great for scenarios where multiple profiles need to be created. In turn we can store the data in a single call and cache it in the session for further processing. Another more prominent example of cloning would perhaps be in the form of a bank account. Where you would want to make a copy of the object that holds your account information, perform transactions on it and then replace the original object with a modified one (a clone). The blog then goes on to list some more interesting points of the design pattern as well as some benefits and drawbacks. One of the drawbacks of the pattern is that classes with circular references to other classes cannot really be cloned. But a benefit of this pattern is that client can reduce subclassing with this immensely. All and all this pattern seems like something I would use actually quite often.

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

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

For this week’s blog post I will be looking at another design pattern, this time called Façade. This time once again from the handy site of SourceMaking.com. The overall intent of the design pattern is to provide a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, wrapping a complicated subsystem with a simpler interface. The problem that faces it is a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. Essentially façade discusses encapsulating a complex subsystem within a single interface object, thus reducing the learning curve necessary to successfully leverage the subsystem. The only access point for the subsystem will limit the features and flexibility that power users may need. The façade object should be a fairly simple facilitator. “Façade takes a “riddle wrapped in an enigma shrouded in mystery” and injects a wrapper that tames the amorphous and inscrutable mass of software.” With the quote from the site above the name really comes into play here. A good example of this would be something like that of a catalog. Where the consumer calls one number from the catalog and speaks with costumer service. The customer service representative acts as a façade, providing an interface to the order fulfillment department, the billing department and then the shipping department. Façade defines a new interface where in the Adapter design pattern it uses an old interface. The site/article then goes on to explain some general rules of thumb that can prove useful to those wanting to learn more or follow the design pattern even more. All and all the site is an excellent resource for anyone looking to learn more about design patterns and more with this article proving that with valuable information on a new design pattern I have not seen or used before.

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

Acceptance Testing

For this week’s blog post I will be discussing another form of testing called Acceptance testing. Acceptance testing is a form of testing where a system is tested for overall acceptability. The reason for this is to see if the systems compliance with certain business requirements and assess whether it is acceptable for delivery. The site shows a helpful diagram illustrating when you uses this testing, with Unit Testing on the bottom, Followed by Integration testing above that, System testing above that and with Acceptance on that the top of that one. The site also gives a good analogy of what it is exactly happening with the illustration. During the process of a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are all produced separately, and unit tested separately. After this they are assembled and begin integration testing, with System testing following this. With of course Acceptance testing last to confirm once more that the pen is ready to function properly. Black Box Testing is the most common method used in performing Acceptance Testing. The testing does not follow any strict procedure and is not scripted but is rather ad-hoc testing. Ad-hoc testing is random testing or Monkey testing, essentially throwing stuff at a wall trying to see what sticks and what does not. You perform this testing after system testing like mentioned above in order for the system to be made available for actual use. Internal Acceptance Testing is performed by members of the organization that developed the software but who are no directly involved in the project, usually this is members of the Product Management, Sales or Customer Support. The opposite end of this is known as External Acceptance Testing where it is performed by those who are not employees of the organization that developed the said software. This is then broken up into two different fields, Customer Acceptance Testing and User Acceptance Testing. Customer Acceptance Testing is a pretty self-explanatory name where it is performed by those who purchased the software or are customers of the company that developed it. User Acceptance Testing is performed by the end users of the software, customers’

Customers essentially.

All and all this website was pretty well organized and explained everything very clearly and so forth in a manner where it made extremely simple to read and understand.

http://softwaretestingfundamentals.com/acceptance-testing/

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

Sanity Testing

As a follow, up to my Regression testing post a few weeks ago, Sanity testing is almost a subset of it because it is performed when we do not have enough time to do the testing. It is used to carry out the checking on whether the bugs reported in the previous build are fixed with regression being introduced to fix these issues not breaking any of the previously working functionality. Sanity checks to see if the functionality is working as intended/expected instead of doing the entirety of regression testing. The test helps avoid wasting time and cost involved if the build has failed. After the regression introduction has been completed Sanity starts to kick into full swing. With it checking the defeat fixes and changes done to the software application without breaking the core functionality. It is usually a narrow and deep approach to testing, needing to concentrate limited and main features of testing in detail. Sanity testing is usually non-scripted helping to identify the dependent missing functionalities. It is used to determine if sections of the application are still working after minor changes.  The objective of this testing is to not verify thoroughly the new functionality but rather to determine if that the developer has applied some rationality while producing the software. For example, if your scientific calculator gives the result of 2+2 = t! then there is no point in testing the advanced functionalities like sin 30 + cos 50. Sanity testing is usually compared to Smoke Testing which is used after software building is completed to ascertain the critical functionalities of the program is working fine. But smoke testing is for another topic for another day. All and all the website I looked at was very insightful into what sanity testing is and what it does.

https://www.guru99.com/smoke-sanity-testing.html

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