For this weeks blog post I will be looking at smoke testing.
A smoke test is used to describe a suite of basic tests that verify that the major features of an application are working properly. A most common se of this is simply to determine whether a build is stable and ready for further testing or a final check before you submit something. The result of this testing is used to decide if what you built is stable enough to proceed with even further testing. The terminology behind the name comes from a similar type of hardware testing in which the device passed the test if it did not catch fire the first time it was turned on. The testing covers most of the major functions of the software but none of them in extreme depth. The result simply is whether or not you must go deeper or not. If it fails you stop further tests and try to fix what you already have. This testing helps expose integration and other major problems early in development cycles. It can be conducted on both newly created software and enhanced software. A smoke test is almost always performed manually with some help of automation tools or scripts but if the builds are prepared frequently automated smoke testing is the best to use. After an application becomes more developed and mature in a sense with more functionality the smoke test will need to be made more expansive. Sometimes even just one incorrect character in the code could render an entire application useless. The advantages of this smoke testing expose integration issues and helps you uncover the issues early.
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.
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.
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..
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.
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.
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 5th 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.