In this blog post https://medium.com/engineering-housing/nan-is-not-equal-to-nan-771321379694 “NaN is not equal to NaN!”, Dron Rathore discusses the IEEE standard of NaN being a value which is not equal to itself. The blog explains some of the definitions and implementations surrounding NaN. It is not an opinionated blog post, it is mainly for the sake of being an educational resource. My particular interest is the actual reason in the first place for why NaN is defined as not being equal to itself. The result of comparison must be a boolean, so the only options for trying to compare NaN to itself are to return true or false, or error and crash. In mathematics, NaN is effectively “undefined” or “indeterminate”, so something like 0/0 is undefined. The truth value of the equation 0/0 = 0/0 is also undefined; the operation of equality is not defined for values that are not defined themselves unless the operation itself is given additional definition to account for that case, which is what must be done for programming languages so that it results in a boolean value. The choice for that value to be false is peculiar and ultimately seems arbitrary, but it is useful for detecting values that are NaN; if (x == x) is false then x is NaN. This blog post does not directly give any feedback on the reason for this implementation of NaN, it merely describes it, but I would like to get some perspective on how the choice is made and how it is more logical to have NaN not equal to itself over an alternative implementation where it is. Comparisons involving NaN may still result in confusing outputs; infinity > NaN is false, for instance, and so is infinity <= NaN, but “not (infinity <= NaN)” is true. For the sake of software testing, NaN adds a lot of strange edge cases where assumptions about equality lead to contradictions. In these cases, or in any case where it is not okay for NaN to exist, it makes the most sense to just have errors instead of trying to deal with this unique behavior.

From the blog cs-wsu – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.

Between many design patterns Mediator is one of most used in today’s software world. In this pattern, the object encapsulates the processes between other objects, without asking other objects to interfere. We are going to analyze a real-world example that uses the mediator design pattern. This pattern serves as a go-between operator, so other components … Continue reading Mediator Pattern →

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

This week’s blog is going to be about “The challenges and benefits of model-based testing” by Greg Sypolt.  In this blog, Greg talked about what model-based testing(MBT) is, how it works, how model-based testing differ from other kinds of testing, the challenges that are faced when using model-based testing, and the benefits of using it. Model-based testing is a kind of test where test cases are automatically generated from models. It focuses on the models based on the system requirements or specifications. The model-based testing works by generating tests automatically from models created by the software developers and testers, then it runs assertions for both generation of tests and execution, and reports the testing results. Model-based testing is different because it is more in the software development process than a scripting task. It focuses more on building a testable application and creating models based on user’s perspectives.  There are many challenges to address before you can use model-based testing to its full benefits. Software developers and testers have to be trained on model-based testing. The tool has to be scalable and be able to handle complex models and provide a reliable test coverage. Fine-tuning the MBT tool could also be challenging. However, it will offset the long-term goal of reduction of test maintenance. Test coverage is guaranteed and there is zero test suite maintenance.

I think this blog post is very helpful in introducing model-based testing. It is fairly brief but still shows you the idea behind model-based testing. This blog post is really interesting since model-based testing is a move away from the traditional testing. Instead of having a set of particular tests with defined test objectives and deliverables that should be achieved, model-based testing is done from models and not from the source code. A thought-provoking section of the blog for me is where he talked about the challenges of model-based testing. Greg said that model-based testing requires a shift in mindset and culture in how to develop and test applications. It made me think of how different it really is from the traditional way of testing. Learning about model-based testing changed the way I think about software testing since it is an approach that I haven’t really seen before. Now, I wonder in the future, what else kind of testing we are going to come up with.

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

Cohesion is one o the most important concepts o Software design, and it’s used as a measurable factor in how strongly are software’s features related and how software’s pattern is consolidated as one frame. Modern software design strategies suggest to use cohesion as a slide ding scale instead of binary attribute as it was introduced in 1974. As … Continue reading Understanding Cohesion →

From the blog cs-wsu – Kristi Pina&#039;s Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Writing Better Tests With JUnit by Tobias Goeschel

For this week’s blog, I chose “Writing Better Tests With JUnit” by Tobias Goeschel. The blog contains different tips and suggestions on how to write a better test in JUnit. It also emphasized the idea that having a readable test code is at least as important as writing a readable production code and that the focus of the test must be on behavior instead of implementation. Another tip was to group tests by context. Grouping the tests by context would help us organize and focus on behaviors that should be grouped together. It would also help to understand the behavior more quickly and easily.  Tobias also talked about enforcing the Single Assertion Rule. The rule was to use a single assertion if possible, but not it does necessarily mean that there could only be one assertion called, there are times when you would want to have multiple assertions. He also emphasized choosing meaningful names for the tests, it would be easier to know what the test is testing and eliminate unnecessary comments. The blog also talked about using other dependency injection frameworks like Spring to keep the tests fast and to avoid overly complex configurations. Lastly, he talked about avoiding test inheritance if possible since navigating the class hierarchy to get an idea of what is happening would make the test harder to understand.

I really find this blog useful. It stresses the idea of test behavior, not implementation. The blog also has some code in it where you can see how the tests are implemented. There are also different patterns that are useful when testing in the blog like the “Triple A” pattern which stands for “Arrange(preconditions and inputs)  Act(things happen, methods are tested)  Assert(see if the result was right)”.  The other thing that I thought was thought-provoking is the use of inheritance. He said that it should be avoided if possible but when I read his explanation, it makes so much sense not to use inheritance. The way he emphasized that tests are as important as production code changes the way I think about coding now. I feel like writing test cases before writing the actual code might be a better approach to writing software.

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