Full Article by Matt Lacey

In this post, Matt Lacey discusses 11 things that developers do wrong when creating and testing their code.

The first one he lists is that developers can just fall into the trap of just not making any tests for their code. He states that a way to fix this is to just start creating tests for the code that you’re already working on and plan to always do this for future projects.
The next item his list is that developers need to design and make tests when they start their projects. This makes it easier to implement into the code that is currently being worked on rather than adding in tests later. Also adding in tests later may require developers to make architecture changes and will add on additional time.
The third item on the list is writing failing tests. Lacey goes into explaining that your should not specifically make tests to fail (or have a red outcome) because the point of writing tests is to make sure that our system is working properly.
The fourth thing on the list is having a fear of unimplemented tests. Having these types of tests (which also have a proper names for the functions they are preforming) will serve as a reminder about the intended function of the system as well as what the test should accomplish.
Fifth on the list is simply not giving your tests good, identifying names. Lacey states that the way you name your tests isn’t important; what matters is that your naming behaviors are consistent, and properly describe what the tests are suppose to do.
The next item is making tests that do too much. Here he gives a reminder that your tests should only be testing one thing; this could even be a series of simple things that make up one task even, but it should not be testing multiple long tasks.
Seventh on Lacey’s list of what not to do is not testing you code. Lacey points out that creating mocks and running them does not actually mean you are testing the code. He states that these types of “tests” could just end up being a waste of time and effort.
The next thing on the list is worrying too much about code coverage. Lacey states the knowing “how much of the code is executed when the tests are run should be useful but because it doesn’t consider the quality of the tests that are executing the code it can be meaningless.” He goes on to say that code coverage is only of interest if the coverage is too high or too low. Lacey then address what you kind of code should be tested then by stating “Does the code contain non-trivial complexity? If it does then you need some tests. If it doesn’t then you don’t.”
The ninth item that Lacey views as a mistake is only doing one type of testing. He states that if you’re only making one type of tests then you are not properly testing your software. It takes a multiple different tests to find mistakes in all areas of your system.
Number ten on the list focusing too much on short term tests. Tests should not be made to test something that is static; like if the code is written correctly. Instead tests should be written the make sure that the code continues to function correctly over time. Tests should be able to be run repeatedly to make sure that no new errors occur if new code is added or changed.
The last item on Lacey’s list of what not to do is being a developer that relies on someone else to create and run tests. Tests should always be available for developers to run if the need arises. If there is something that will hinder a quick execution of tests then that will just prevent developers from running the tests they need. The best thing to do, according to Lacey, is to make sure that “code and tests…be kept in the same place and any setup needed should be scripted.”

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

Full Article by Pavel Novik

In this article, Pavel Novik talks about the phenomena known as the Internet of Things (IoT), and goes over the importance for companies to properly tests the software that is used by these products.

Pavel Novik points out that many companies use IoT products, but more than half of them “do not have a software testing strategy for this specific aspect of their IT infrastructure.” However being able to test certain devices can be an issue, Novik points out, if the company only sells the application for running the devices because they might not be able to have all the products on hand to tests. Novik suggests that companies that are in this position to find out which devices their customer base buy the most, and then limit their testing to those products.

Novik then goes on to talk about what areas should be tested when it comes to IoT devices. The first one that he suggests is security; making sure that no one is able to steal personal information from the devices, and also prevent attacks from happening which may lead to accidents. The second area is performance; this is to make sure that all the data that is being sent between these products without fail even when some sort of disruption takes place. The third area Novik points out is functionality; this is testing “to verify that the application functions meet all the functional requirements,” and that testers should “strive to go beyond general test scenarios, and consider body movements, voice commands and sensor utilization when writing test cases.” The fourth and last area that’s cover is compatibility; covering this area while testing will make sure the product works with other versions, devices, and systems that it you may encounter further down the line.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.