Source: https://blog.bugsnag.com/better-software-testing/

I found a blog post called “You don’t have enough tests and you never will!” by William Starling. This post he talks about how there is never enough tests for coding. The reason why people do test is because the earlier you find a bug the cheaper it is to fix it. The sooner a developer finds the bug right after writing the code they can quickly fix it. He then goes off by talking about different tests such as unit testing, integration testing, and system testing. Testing is hard and software is complex. No matter how many testing you do there will always be a bug. He says a lot of software teams gets too caught up on trying to measure how much testing is being done. Sometimes they would do an unhelpful testing that would say the program is 100% correct but they are testing for the wrong behavior and the test itself could be buggy as well. So what is the best testing strategy? Typically the best is where you are testing for major and the most obvious bugs at first. Then you would test things that would affect the security or integrity of the program.  An example he talks about is that what if you want to make a self-driving car so you don’t want to have it drive off the road thinking it’s still within the lines. More tests does not mean there are going to be less bugs. Focusing the tests in the right places can be the difference between a good code and a bad code. Examples of areas where testing can make a difference is complex logic, public accessible interfaces, and high impact code. You should also design your code to be able to modify later on to fix those bugs. Once the program is out for the public the best way for bug testing is the consumer themselves. When people are using the software they will find things that many programs will never think of so that way.

I chose this blog because testing code has come up a lot whenever I write code. In class, we do code that no matter how we wright it once it prints that final line we are done with it. However once we get out into the real world we are going to be writing code that will be used constantly and would be seen by billions of people and sometimes it won’t run the way that we expect it to and we would have to fix it so reading up on how to text and what test we should do is a good way to prep-ourselves for future projects

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Source: http://blog.cleancoder.com/uncle-bob/2017/02/23/NecessaryComments.html

Recently, I read up on the blog cleancoder, by Robert C. Martin on Necessary Comments. The blog talks about how having a comment on every single piece of code that you wright is unnecessary. He says that when coding adding comments should be a last resort. He later even gives a good example of when this should be used. He was working with another member of his team for an improvement for their website. Whenever a customer purchases a video from their website it would then also find all the videos that had been purchased by others who had bought that video, and would pick the most popular and recommend it to the customer. They did not want the customer to wait forever for the suggestions so they decided to put the long running functions into another function that would return the previous result from the cache and if more than the N minute had passed, would run the algorithm in a separate thread, and cache the new result. They called this function the “choke function.” However, when they were testing it and trying to improve it when they tried to have other read the code most people would not know what they were trying to do so they kept going back to the diagram and that was wasting time. So, they decided to make a longer explanation of what the code did and they also drew in a diagram. Robert said “This doesn’t happen all the time.… But it does happen; and when it does nothing can be more helpful than a well written, well thought through, comment.”

I decided to read up on the blog because I was taught to have a comment on every line. This way it is clear on what I am doing and if I make a mistake it would be easier to find where in the code it is in. After reading this blog I can see why writing comments on every single function is useless because in the real world there are people who know what you are talking about. However, if you do decide to write a comment on a function make sure it is a well written, well thought out, comment. For myself I think I will still write comments on many of my functions however if it is very simple and easy to understand I will not waste my time writing it.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.