https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html
This week we analyze why a code may be STUPID. What makes code STUPID are the following:
Singleton
Tight coupling
Untestability
Premature Optimization
Indescriptive Naming
Duplication
Singleton, what is wrong with that? According to the example code provided in the article, the singleton allows access to the DB from anywhere using the getInstance() method. In addition, it ensures that there is only one database connection at a time. This is not an issue until a second connection to a different database is needed. In this case, when the application grew larger, the developer needed to change the singleton to have a getSecondInstance(). However, this isn’t a singleton anymore. Another issue is that the getInstance() function binds the code to the DB classname. This means that the DBclass can’t be extended. In this case, when a developer wants to optionally log query performance data to the APC, tight coupling to the class name will not allow it to do so. Dependency injection would have solved the problem, however this is not allowed in singleton pattern. What the writer introduced was what can be called a “hack”, but this is bad coding practice. The last point to be disappointed in is that the getInstance() method allows global access from anywhere using the DB. However, in PHP we learned to avoid the use of the global keyword. Global instances in singletons creates non-obvious dependencies, making the app harder to reuse and test. So, this is impractical coding practice.
The singleton issue can also be generalized to the issue with static methods and properties. For example, the Foo::bar() method will tightly couple the code to the Fooclass. This prevents the Foo function from being extended. This makes it harder for the code to be reused and tested. The example provided is the House class with the constructor function for the variables door and window. The question to ask is how would you replace the door or window in the house class. The answer is you can’t! Instead, the dependency injection can be introduced, however the House class is an example of stupid code.
Finally, we stop at the U in STUPID which stands for untestability. Unit testing is important and if we cannot test we cannot verify its proper functionality. If we don’t test we can end up with broken code. Making a code hard to test is in this case stupid code. What makes a code hard to test? — tight coupling. Dirty hacks can be used to avoid these issues, but we would rather not have broken codes in the first place. Overall, good coding practices means that it can be easily tested.
I chose this blog post because it introduces the disadvantages of the singleton design. This further intends what I have learned in my first blog post on Singleton patterns. Singleton in this case is criticized even for its advantages in creating a global state for a single instantiation. In this case, it is criticized as stupid code because it does not allow the developer to extend the code without modifying it to include a second instance, making it a dupleton.
I chose to learn about STUPID coding practices in order to improve my own coding practices as a developer since it provides good examples for how to avoid bad code and how to improve upon it. By, following some of the guidelines introduced here, this helps to make the code easily extensible without modifying its previous functionalities.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

https://blog.testlodge.com/software-testing-best-practices/
This week we ask what are the best practices for testing. Although this article suggests 6, we will only discuss 5 in this blog post. The first as discussed in the article is to understand the project objective. It is critical to understand the objective of the overall project from a business and technical perspective. It is also important to have every member of the team know the project’s goals, not just the scope of their testing. Although it is typical for the whole project to be divided among several team members with each team concentrating on only their area of testing, it is always beneficial to have the entire application and architecture in mind. This helps them to know about all of the different components, dependencies, integration points, and data flow. It is also useful for testing defects to be aware of the whole application flow to be able to nail down the root cause. Overall, knowing the objectives helps to identify better test scenarios.

The second best practice is to plan and define strategies. Planning is crucial for success. Therefore, it is recommended that every software developer makes it their daily routines. The article suggests the following activities as part of test planning:

Select the resources with the right skill set.
Identify risks.
Prepare test schedule.
Define strategy, which includes defining the overall strategy/plan to be taken in order to test an application.

The third best practice is to design scenarios and enforce reviews. Standard design phases includes the development of test scenarios and test cases and the typical reviews by stakeholders.

The fourth best practice is the obvious, communication. Every working team requires communication either through emails, the phone, on chat, or in person. What is the case where there is a lack in communication? Consider a defect that has been marked as fixed by a developer. Once the team tests it and finds out that it is not working properly, they mark the issue as unresolved although the other development team had stated that it had worked fine on their end. This demonstrates a lack in communication. The best solution is to mark the defect as unresolved and provides specifics and detailed explanations on what had been tested on multiple browsers and could not be corrected. The key is to be as detailed as we can be in our communications with the other development team.
The final best practice is to identify the scope of automation. Automation in this case can be achieved by writing scripts to perform a repetitive job. This helps to reduce manual efforts. The article suggests the following tips to help in identifying the scope of automation:
Identify the most difficult area that you hate to do, but crucial in the test design, meaning you are forced to test it. The second suggestion is to focus your attention on how to automate the task.

From the 5 best practices, however, I found 3 to be the most useful and that is to know the overall objective of the whole project, to plan around it and finally communication is always the key to a successful career. From experiences with software development, I found that adhering to the overall goals of the project helps to organize the code, which is what every programmers wants and it is what these guidelines and principles teaches us about, that is to clean up our codes. Knowing the overall objectives of the design helps to keep the team on track and it helps to create cohesiveness in the product. This helps to reduce defects and debugging. The other guideline that I found most useful is effective communication, which is require in every field of study. Effective communication helps to speed along the project.

Overall, I chose this blog post in order to compare the suggested best software testing strategy with my own experiences in software development. I found the first, second, and fifth guideline to be useful in software development.

From the blog CS@Worcester – Site Title by myxuanonline and used with permission of the author. All other rights reserved by the author.

Considering we’re discussing JUnit in class, I want to learn how to use it as efficiently as possible. For those who are not aware, JUnit is a popular unit testing framework for the Java programming language. Since unit testing is an important concept in Software Development, learning more about the workings of JUnit should not only help me with my studies, but also with my professional career.

I found a good blog offering some tips and pointers on the subject, entitled JUnit Best Practices by Kyle Blaney. The main point seems to focus on the importance of performing efficient unit testing with the JUnit program.

Before going into JUnit specifics, Kyle starts off by stressing that unit tests ought to be “extremely fast” and “extremely reliable.” Due to present technologies, we seem to expect computers to run at the proverbial speed of lightning. Because of this, I believe it is considerable to expect each test to be completed within milliseconds. Also, I agree that unit tests should be reliable in the following sense: they should be failing when the code is broken and passing when the code is not.

In regards to JUnit, Kyle brings up quite a few points, the following of which I felt specifically relate to the course material. This pertains to what we’ve previously discussed about unit testing so far, and what we will likely be covering in the near future.

Kyle explains that we should be running our JUnit tests completely in memory. This means we should not be accessing outside resources during our testing. I agree, because if we cannot get a reliable connection on these outside resources, it will only slow down or possibly halt our unit testing completely.

Another important point that Kyle brought up is that unit test methods should only be performing one assertion. His reasoning is as follows: we cannot be certain that all the assertions occur even if the method appears to have passed. This seems to be in relation to something we’ve learned in our school’s computer science program: “Methods should do one thing and one thing only.” That way, it is much easier to trace our code and figure out what it is supposed to be doing.

We’ve also discussed in class that we should be using JUnit assertion methods that best match the context of our testing. One example Kyle gives is when to use assertTrue versus assertEquals:

Use assertTrue(classUnderTest.methodUnderTest()) rather than 
assertEquals(true, classUnderTest.methodUnderTest()).

Kyle goes into great details within his blog. Along with the points that I’ve discussed in my own blog, he offers code samples of what not to do, and most importantly, what we should be doing to perform the most efficient JUnit testing possible. I found his blog to be quite helpful and learned a lot from reading his take on JUnit “best practices.” Because of this, I expect his strategical insights and sample code will be useful to me in my future career in software development.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Model-View-Controller

          This week, I chose to write about a blog that went over the understanding of Model-View-Controller. The post first started by explaining each term separately by saying that the Models represented the knowledge while the View was a visual representation of the Models and the Controllers were the links between the user and the system. It talked about Models first, saying that most of the time there should be a one to one correspondence to make sure everything is easily understandable. The blog then goes on to talk about Views as a presentation filter, it would be used to easily convey information. As stated before, this is helpful when it is a visual representation of the Model but it can also be connected to the model which allows it to know more about the attributes and data. This leads to the controllers that essentially allow the user to see outputs based off of menus and other ways of giving commands and data. It uses this output to then make changes back in the Views section which will them give out another output.

          I chose this article because it seemed important to know more about how to explain code using models and controllers in this sense to other people. This post used examples that allowed this idea to be understood much easier for me, as the summary was a bit confusing. When they used the example of HTML code in the browser it made much more sense. The way I understood it after that was that the model was the information the creator wanted to put into HTML while the CSS was the view which acted like the “code” that displayed everything in a clean visual representation. This all came together within the browser which they linked to a controller as it is what combines and connects the entire thing. As I said before, the content had ok definitions but the examples they used made up for it since it allowed an easier understanding. I thought this topic was important since we will be learning about this subject as it is a software architectural pattern. This material affected me by showing me a system to show the user simplified information through the use of code. I think that if this were to be implemented within coding, it would be best used as a way to reuse code along with implementation of user interfaces. As a software architectural pattern, I could see this being important to future practices as it seems to be used a lot within popular programming languages and even web application development.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.