Today I will be talking about a blog called “Unit Testing, How to Write Testable Code and Why it Matters”. This blog talks about the importance of unit testing for anyone who is a software developer. The blog talks about what unit testing is, what it consists of, and something that I had never heard of until today; the three A’s of unit testing:  Arrange, Act, Assert. We will talk about these three A’s of unit testing in more detail later. Another thing the blog talks about is unit testing vs integration testing. The blog sums up the difference between the two as unit tests have a narrow scope to test just one small part of the program whereas integration tests test how the “pieces” of code fit together and work hand in hand. Essentially, integration testing is a larger scale version of unit testing. So what exactly makes a good unit test? According to the blog, good unit tests consist of tests that are easy to write, readable, reliable, fast, and truly unit testing (not integration testing). This is where the three A’s of unit testing come into play. After you make sure that your unit tests adhere to the rules of good  unit testing, you can apply the three A’s of unit testing. The three A’s (as mentioned before) are Arrange, Act, and Assert. Firstly, we arrange. We do this by testing small portions of the code (unit tests) to ensure they work as designed. Next we give the test some sort of input to “test” its function to make sure it works correctly, this is also known as the Act phase. Lastly, we Assert what we know our output should be and we then compare it to the output of the function we are testing.

I think this is an extremely important article because it has given me a lot of insight on how to make good unit tests and how to make the testing cycle easier by remembering the three A’s of unit testing; Arrange, Act, Assert. I hope to use the three A’s of unit testing in my future programs in hopes that my testing will go smoothly and quickly. Another thing the article talked about that cleared up some confusion for me is unit testing versus integration testing. For me, the two have always been kind of interchanged and intermingled, as they are very closely related. I think that many people know there is a difference between the two, but do not know exactly what that difference is. It is good to think of it as integration tests being larger scale unit tests. In my head, I now think of integration tests as being made up of smaller unit tests, and seeing how those unit tests work together. I think this article was overall a really good read and will make my approach to writing tests for my programs change for the better.

Here’s The Link: https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

In my last blog post, I briefly mentioned the idea of Test-Driven Development (TDD) as a process for creating programs, as well as its tying-in to Behavior-Driven Development (BDD). I wanted to learn more about TDD, so that will be the topic of this post! The article that I chose to read came from the following website: https://www.stickyminds.com/article/value-test-driven-development-when-writing-changeable-code.

This article touched upon concepts presented in both of the software development courses that I am taking (Software Design, Construction, and Architecture; Software QA and Testing). It highlighted the importance of making code that is easily changeable using techniques such as abstraction, encapsulation, or various design patterns. With this kind of coding strategy, developers don’t have to be as concerned about the whole program being affected when a few lines of code are revised. This is associated with more of the software design side of TDD. However, the process by which TDD takes place focuses on software testing, where further code is not written unless the automated and continuous tests produce a failing result. These tests are also written independently of the code being implemented. In other words, the code being tested is considered to be black-box, and the tests are made to uncover the failures in code, from which revisions will be made. This is where changeable code comes into play. This kind of coding mentality strives to ensure that the entire functioning of the program won’t break when the code is changed. This includes the automation of TDD; when the entire program is being rewritten because of a lack of changeable code, this may have additional effects on the testing process.

However, the article is quick to note that while TDD is a way to specify code behaviors by continuously testing and fixing code, it does not replace the process of Quality Assurance. With QA, the potential for code and tests to go wrong, as well as possible ways to navigate around these problems, are all considered. TDD is more “implementation-independent,” where the tests being run are not to assess the way behaviors are implemented in code, but in a more general sense, to simply express the behaviors that the program aims to implement. TDD, in a way, shows the specifications of a given program, and with continuous testing, can exploit the holes in a program so that they can be further improved.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

This week’s blog is about the four levels of software testing.  There are four main levels of testing that needs to be done before a program is ready for use: unit testing, integration testing, system testing, and acceptance testing.

Unit Testing

Unit testing is the first round of testing. In Unit Testing, the program is assessed with the focus on specific units or components of the software to determine whether each of them is working correctly. A unit can be referred to as a function, an individual program or even a procedure. The white-box testing method is usually used to do this kind of job since it is based on the analysis of the internal structure of the system or component.

Integration Testing

Integration testing, on the other hand, allows you to combine all of the units within a program and can be tested as a group. It is designed to find interface defects between modules or functions. It is very useful because it measures how efficiently the units are running together.

System Testing

System testing is the test ran after the application is actually completed and tested. The goal of this test is to check whether the system met all the requirements and see if it meets the Quality Standards. This test is done by testers that were not part of the development team. It is performed in an environment that’s somewhat the same as production. System testing verifies that the application meets the technical, functional, and business requirements that were set by the customers.

Acceptance Testing

Acceptance testing is the final test. This test basically determines if the application is ready to be released. During this phase, the users test the systems to find out if the application meets the business’ needs. Once this is completed, the application is ready to be delivered to production.

I find this blog interesting because at first, it looks like a really simple process to create an application and put it out on production but there are actually different levels to it. This has changed the way I think about software development. Just thinking about the process of testing the application, I could already see it having a great importance in software development. Also, you could be moving back and forth on the different levels of testing when the specification changes.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

https://dojo.ministryoftesting.com/dojo/lessons/testing-for-developers

This is the first time I’ve heard the ministry for testing’s super tester bros and from the Mario themed intro, I already appreciate the pure nerd culture of this podcast. They open the conversation with a discussion about a malware app, a clone of WhatsApp that tricked people into downloading spyware. This is a common problem, most searches bring up some kind of harmful software further down the results.

The conversation continues into various avenues revolving around security, particularly regarding a recent flaw in Apple’s sign in program. For a short period of time, anybody could sign in without credentials by clicking “Sign In” enough times with a blank username and password. This simple-to-use security breach is unexpected for a company as big as apple, since this is a type of problem could be avoided by better testing and coding.

At the 19:30 mark, they brought in two developers to talk about how they work with testers. Although the target in a dynamic software development environment is to release the product in working order as quickly as possible, they both express that there is a lot more value in collaboration over rushing. The quality of the end project doesn’t depend solely on the tester or the developer alone. Having a tester by the developer to share insight and do some “peer testing” will also help the developer understand how the further processes work, so he may be able to design around them. This will help save time in a project, since the developer wants the code to pass, or at least not fail, on the first few attempts after handing it to the tester.

Towards the end of the podcast, the hosts shared stories about encounters in their career. A typo was detected on the front page of a company that one of the hosts worked at. At the time, this error was given a low priority score since it didn’t actively change or effect the working order of the website, however, he reflected on how many people saw that typo and immediately disregarded the website as worthy of doing business with. In that way, this small error was in fact very high priority and greatly changed the effectiveness of the website to bring in customers in a way that had nothing to do with its true functionality.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

http://news.mit.edu/2018/model-helps-robots-navigate-like-humans-1004

A paper describing a model where researchers combined a planning algorithm with a neural network that learns to recognize paths that lead to the best outcome, then use that knowledge to guide a robot through an enviroment.  The researchers demonstrate their model in two settings, navigating through rooms that have traps and narrow passageways or navigating through a room without any collisions. This learns by being shown a few examples of similar eviroments and then bases its actions on that. For example, if it recognizes a door it will know to exit through it based on the learned examples all exiting through a door. This model combines older, more common methods with this new look at machine learning. The planner creates a search tree while the neural network mirrors each step and makes a prediction based on probabilities for possible actions to take. If the network has high confidence of success it will act on it, otherwise it will fall back on exploring the enviroment like the tradititional method. One application for this model is autonomous cars where there are multiple agents all operating at the same time in the same space. For autonomous cars intersections and especially roundabouts are extremly challenging since there are numerous cars moving around a circle going in and out all at once. Results indicate that this model of machine learning can learn enough behavior based on previous experience to be able to navigate something as that challenging. In addition, they only needed a few examples of very few cars in a roundabout to be successful.

I find this article to be interesting since autonomous cars are going to be extremely popular in the future. This model is another advancement toward getting self driving cars even more independent to the point of something from a sci-fi movie. In addition to that, having something to efficiently navigate a room is important for other applications such as assisting somone that is blind. Something like this could give someone who has to rely someone else more independance if all they need to do is wear some glasses that tell them where objects in the room are located and how to navigate around them.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

Greetings reader!

In today’s blog,  I will be discussing the differences between black box and white box testing. This blog will briefly explain the benefits for each test, as well as point out their distinct features. I will also be sharing my analysis of QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article from which I read. Without any further introduction, let’s begin.

Black box testing (BBT) is a testing method in which there is no access to the source code or the internal structure of software. The main goal of BBT is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors.

Some advantages of black box testing are as follows. First, the tester can start designing test cases just after the specification is ready. Secondly, tests preparation time is short, and finally, there is no need for a tester to know the programming language of the application. The disadvantages of black-box testing: it is hard to design test cases without a specification, only some paths are covered , and it is impossible to to see what part of the code can cause a problem in future.

White-box testing (WBT) is a testing method where there is access to the source code and internal structure of the software (opposed to BBT). This testing type insinutates that a tester knows which code line is called for each function. It allows the tester to better choose an entry data set and to check errors and exceptions efficiently. White-box Testing focuses on bad code writing, conditional loops, the working flow of the code, and memory leaks.

Advantages of white-box testing are: there is no need to wait for the GUI application, it can conduct more detailed testing with more cases covered, and it can predict the potential problems in the software. The disadvantages of white-box testing is that a tester must know the programming language of the software, it can take much more time than other methods, and it can be expensive.

To conclude, there are advantages and disadvantages to both methods of testing, so there is none that is “better” than the other. They are both necessary and complementary.  The QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article that I read was extremely informative and very easy to comprehend. I greatly recommend their articles to expand your computer science knowledge.

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

In his post “The Psychology of Design”, Blogger Jon Yablonski writing for the blog “A List Apart”, discusses the importance of software developers to understand some principles about heuristic psychology that are helpful in improving user experiences and overall design.

Yablonski begins by explaining the concept of Hick’s law, the notion that the amount of time it takes a user to respond to a situation depends on the volume of information the person is presented with. He uses the example of a television remote, and how as the number and complexity of devises increases, the more confusing the remote controls become. But by abstracting the features to those only absolutely necessary, we’re able to create a much more user friendly product, as demonstrated by the apple TV remotes.

The author also goes into the idea of Miller’s law, which is the assumption that people can commit to memory seven plus or minus two different objects. Yablonski goes into strategies designers have used to work around this inconvenience; namely chunking. Chunking is used to break up large or complicated amount of information into chunks, like the digits in a phone number, or breaking up a news page in discrete parts.

Finally, Yablonski explains Jakob’s law, that people tend to form their expectations based on previous models that we have learned. For example, most video game controllers tend to have a similar arrangements of inputs. This serves to lower the learning curve required in adopting a newer model.

Personally I think heuristic psychology is very useful in the area of software development. Understanding how our minds process information is an integral source of data to help us achieve our goals of creating efficient, user friendly software. By applying smart strategies like design patterns to help implementation, combined by the insight of psychology, we should be able to handle a broad range of situations and have a good array of tools to help solve the problem.

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