Monthly Archives: May 2021

The Path to Path-Testing

When we went over Path testing in class a couple of weeks ago it really caught my eye. Could it be because it is a very visual topic/idea in a class consumed with code? This could lead to why this topic really stood out to me but also this idea made a ton of sense to me. It also made everything much clearer to me as it gave me a visual representation of what we were talking about, and as a visual learner, i love nothing more.

Path testing is a structural testing method that involves using the source code of a program in order to find every possible executable path.Since all code has multiple entry and exit points, testing for each of these points is time-consuming as well as a little complex at times. In order to maximize test coverage and provent yourself from testing for the same thing over and over again we use path testing to help us visualize and see the independent paths taking in the code to help us see what to test for.

A very basic idea here but a very effective one at that. Steps to this test are very bsaic as well though, as they include generating control graphs, which is kind of like a puzzle in the mix of all this that really clears everything up once you have solved it. You then find a basis set of paths and generate test cases for each path.

This process really helps you focus on the logic in the program, and really helps reduce your test code from testing for the same thing. And really makes you see all possible scenarios in which you should be making test cases for as well.

As a stronger visual learner, this concept really stood out to me when we were going over it and for others that sometimes get confused with the pages and pages of code involved here, this is a nice small change of pace to clear everything up.

source: https://www.guru99.com/basis-path-testing.html

From the blog CS@Worcester – The ways of the Computer: A Blog by JTekelis by jtekelis and used with permission of the author. All other rights reserved by the author.

Reading list

The most valuable thing you can get out of any book is a list of other books worth reading. Over time, you will find that certain books keep popping up from the “bibliography”, and you should move those books to the top of the reading list. Other books will sink. Since the reading list is essentially a priority queue, you’ll eventually find that some books sink so far down the queue that you may never read them again.

Start by picking a broad book to give you a general idea of the subject you are aiming for. Then choose a few specific books to master the aspects of the topic that interest you.

Reading the right book at the right time will have a better effect. A lot of reading can improve your reading ability. You will also improve your knowledge of the outside world through reading. For computer science, reading a lot of the latest information will be of great help to your future work and research. Reading will improve your horizon and enrich your spare time.

Even if you read a good book on programming every two months, which is about 35 pages a week, it won’t take long for you to gain a deep understanding of our industry and differentiate yourself from everyone around you. — Steve McConnell, Code Complete

Focusing on the classics also carries a risk: you devote too much energy to them, at the expense of more pragmatic knowledge and information that would improve your everyday skills. Make sure to mix classics with modern, more pragmatic books and articles on your reading list.

In practice, algorithmic problems do not appear at the beginning of a large project. Then, all of a sudden, they appear as subproblems when the programmer doesn’t know how to proceed or when the current program is clearly inappropriate. — Steven S.Skiena, Scenario Analysis of The Algorithm Design Manual

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

Decision Table – Based Testing

For the fourth assignment in software testing, we had to create a decision table testing. A decision table is a black-box test technique that visually presents combinations of inputs and outputs, where inputs are conditions or cases, and outputs are actions or effects. A full decision table contains all combinations of conditions and actions. Additionally, it shows the causes and effects. Therefore, this technique is also called a cause-effect table. A well-created decision table can help to sort out the right response of the system, depending on the input data, as it should include all conditions. It simplifies designing the logic and thus improves the development and testing of our product. 

The decision table works on input conditions and actions. We create a Table in which the top rows are input conditions, and in the same vein, the bottom rows are resulting actions. Similarly, the columns correspond to unique combinations of these conditions.

Advantages of Decision Table Testing

The system behavior is different for different input, both equivalent partitioning, and boundary value analysis won’t help, but decision table can be used.

It can be easily interpreted and is used for development and business as well.

Help to make effective combinations and better coverage for testing.

Any complex business conditions can be easily turned into decision tables.

In a case we are going for 100% coverage typically when the input combinations are low, this technique can ensure the coverage.

Disadvantages of Decision Table Testing

The number of inputs increases the table will become more complex.

Resources:

https://www.guru99.com/decision-table-testing.html

Decision Table Testing

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Static Testing Tools

As this is the last blog I will be writing for this course, I thought it would appropriate to have it be about one of the final topics that I’ve learned; static testing tools. First of all, what is static testing? It’s a form of software testing that tests the code without needing to execute it. This method of testing is useful for finding and resolving errors during the early stages of the program. This also reduces the amount of potential errors that could appear during later stages of development. There are tools which are used to accomplish this form of unit testing that I’ve had some recent experience with. I’ve learned about a few of these static testing tools, and the ones that I would like to touch upon in this blog are checkstyle and Jacoco.

Checkstyle is one of the first static testing tool that I’ve used, and so I’ll talk about it first. The purpose of this tool is to check that the code being tested follows a specific coding guideline that has been preset. The process of doing so it automatic and so it allows the tester to be able to make sure that the coding standard is properly followed while also being able to save time of checking this themselves. While this tool can improve the quality in the presentation of the code, it can’t detect any coding errors having to do with the logic of the code.

Jacoco is a static testing tool that provides code coverage. It measures line and branch coverage by running various test cases, and displays the result with a visual report that shows which lines of code have been tested and the percentage of the amount of code that executes in each method. This allows the tester to be able to determine which parts of the code need more development.

Static testing tools are great resources for unit testing and can improve the overall development of the program by checking for errors at an early stage. These tools can be used simultaneously to check for multiple issues with a program at once. Checkstyle and Jacoco can both provide information to the tester that allows them to be aware of errors at each stage of the code, which makes the process of development more clear when building the program.

Useful links:
https://www.guru99.com/testing-review.html
https://checkstyle.sourceforge.io/
https://www.blueacornici.com/blog/code-coverage-with-jacoco/

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

Test Doubles

Test doubles are a method of unit testing that allows a user to test how the code interacts with an external dependency. It is intended to focus on the code being tested rather than the behavior of the external dependencies. As such, a preset object is used to represent those dependencies and their intended behavior. This allows a section of code to be tested even when its external dependencies are not yet finished or are not yet working. There are several types of objects used as test doubles: dummies, fakes, stubs, and mocks.

Dummies are objects that are passed but never used. In most instances, they are only used to fill out a parameter and are used as a placeholder for arguments.

Fakes are objects that simulate the external dependency by implementing the same interface without interacting with any other objects. Fakes are typically hard-coded in order to represent the correct behavior and must be modified whenever the interface is modified. A new fake object must be created for every unique test case.

Stubs are objects which return a result based on specific input, and they do not usually react beyond the scope of the test. Stubs will usually have all the methods required by the external dependency but will provide hard-coded returns that may need to be altered depending on the test case.

Mocks, much like stubs, will return a result based on a specific input. Mocks can also be programmed with data like the number of times its methods should be called and in what order.

Sources:
https://devopedia.org/mock-testing
https://www.telerik.com/products/mocking/unit-testing.aspx

From the blog CS@Worcester – Ciampa's Computer Science Blog by graceciampa and used with permission of the author. All other rights reserved by the author.

Code Reviews

This week I wanted to learn a little more about code reviews. As first I thought, “Yeah code reviews just get someone to look at your code isn’t that common sense?”. After looking into it more I learned code reviews have a lot of benefits that you might not think of.

Code reviews share knowledge. Most people are going to be working as part of a team. With code reviews there is always more than one person that understands some portion of the project. This makes the team more flexible. With this shared knowledge also comes a better ability to estimate how much work some portion of the project is. When the reviewer gives feedback the are also exposed to the complexity that may underlie an issue. This gives multiple informed inputs to create more reliable estimates for the team.

Code reviews also give you a break from the monotony of a certain task. If you are spending a lot of time on a certain part of the project, doing a code review is like a breath of fresh air. It is liberating to work on a different area of the project. It can even feel fun, almost like a vacation.

Code reviews can also motivate developers to work harder. When you know one of your peers is going to take a look at your work you might take an extra effort to create something you find presentable. You would want your code to be clean and for all your tests to pass.

Code reviews are really more than just having someone else look at what you have done. They are an important part of any software development team and deserve to be formally incorporated into the development process.

atlassian.com/agile/software-development/code-reviews

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

The Long Road of Progress

Photo by Anastasiya Vragova on Pexels.com

The long-term development of a career and set of skills is something not often focused on when discussing professional fields, rather the immediate benefits of that career (money, prestige, the conceptual notions of ‘success’) are more often discussed than not. While succeeding and generating an income are both important aspects of a career, the process of acquiring new skills and knowledge over the span of that career is just as important, if not moreso.

In chapter 3 of Apprenticeship Patterns, (link: https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch03.html#the_long_road), Walking the Long Road discusses the idea of focusing on the journey (learning) rather than the destination (money/success). While the authors acknowledge that these things can often come together with the acquisition of knowledge, the main idea is that learning itself should be (or should become) a rewarding process over the course of a career in software development/programming. Rather than focusing on the “goal” when trying to improve, the goal rather should be trying to improve indefinitely.

This idea of constantly learning and focusing on the process of improvement rather than a high-paying position is appealing to me, as it focuses more on the creative and constructive possibilities of programming rather than on simply turning a skill into profit outright. While income is a necessity and a benefit overall, oftentimes many of the best paying jobs seem to be “manager” type positions where you might spend more time delegating tasks to others than working on those things yourself. The benefit of having higher income is unfortunately offset by the downside of being unable to accumulate practical experience in the process.

I would estimate then that the best positions relative to constant improvement would be ones where creative solutions are possible, or maybe even encouraged. Open-ended problems often seem to involve improvisation or learning new skills by necessity, and in many cases software development does seem to involve this kind of thinking. I would imagine that active development jobs are best when operating with these goals of self-development, since they so often involve open-ended problems which require learning new concepts.

While I do think that focusing on knowledge for the sake of it is a good way to approach things in relation to career development, finding a balance of learning and exercising known or learned skills is important as well. This pattern focuses on the long-term journey, but I think the shorter term “refinement” of maybe more familiar ideas is similarly important. A healthy balance between these two areas is likely best in practice.

Text Referenced: https://learning.oreilly.com/library/view/Apprenticeship+Patterns/9780596806842/ch03.html#the_long_road Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman

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

Erockwood Post #5

An important part of software testing is the testing of the software itself. But what if you were able to automate the testing? One of every programmers core ideals is to try to automate as much as possible, because programmers are “lazy”. One framework that allows you to do this is Gradle. Gradle is a build automation tool rooted on JVM, so it is perfect to use with Java. We can use GitLab’s Continuous Integration tool to allow our code to run and test every time it is pushed to GitLab. This is very useful so that any changes made are automatically test each and every time an update is pushed to Main. Once you have your Java project set up, you need to initialize Gradle into the directory of the Java project. After you have done that, you can copy your Java files to the Main src folder in the new Gradle section in the directory. All of your test files will go to the Test src folder. You can then run gradle build to build the project, then gradle test to run all of your tests in the test files using the files in the Main folder.

After this and gradle test outputs successfully, you can set up GitLab’s Integration by using the .gitlab-ci.yml file in your project. After you have added that, all you need to do is use Git to commit and push your project to GitLab and then check the CI/CD tab to watch your tests run.

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

Reading List

This week I took a look at the pattern “Reading List”. According to this pattern, you should keep a list of books that you intend to read. By making a list of the books you have read and the are going to read, you give yourself an easy way to reflect on your own patterns of studying. As you read you will probably come across more books in the references or bibliography sections. You can add those books to your list as well. Your reading list should also be somewhere online and publicly available. Others may benefit from it or you may benefit from their suggestions.

Despite always being assigned at least one book for every CS course I have taken, I have never (at least until now) considered really using a book to learn about programming or computer science. It seems like a no-brainer to use the internet for anything computer related. Modern search engines allow you to ask extremely specific questions and get almost exactly what you are looking for. Maybe this is because as a student I always know what I need to learn.

As the author points out, it is hard to know where you need to go next or what you need to learn next. I am a student, so I always have a professor who provides a curriculum to follow and assignments to complete. I always know what I need to learn. This is all going to change now because I am graduating in a few weeks. I will have to take the initiative to set my own course of study if I want to improve as a programmer. Without any direction I should probably turn to books.

It is probably time I start reading more books about software development, especially if that is the field I am going to go into. Reading the “Apprenticeship Patterns” book has made me realize books do have a lot to offer aspiring programmers. They are a good way of forcing material in front of you. Because books are restricted by their physical form, authors have to put a lot of material in the book to make it worthwhile. You don’t have to figure out what to learn next; books are carefully curated sections of study, at least textbooks are. It’s about time I start my own reading list too, starting with all the books I neglected to read in the past few years.

From the blog CS@Worcester – Half-Cooked Coding by alexmle1999 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Learn How you Fail

For this week’s blog post, I read the section “Learn How You Fail” from chapter five of the book Apprenticeship Patterns by Dave Hoover and Adewale Oshineye. The quote beginning of the section is what stood out to me the most. It says, “Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change.” The section talked about how sooner or later you may face failures but the right thing to do is push forward at the boundaries and learn to overlook the mistakes you have faced. In our field, we face many failures but that is not holding us back to accomplish the goals we have set for ourselves. The author mainly talked about becoming conscious of the things that trip you but allow yourself the choice of working to fix the problems that are cutting the losses.

One of the most important things to do when you face failure is to accept it and investment of time and effort to make a small improvement. Allow yourself some time and the “goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure.” I liked the example the author provided regarding Ade. Ade keeps a set of private wikis listing all his current skill set and limitations, this enables him to pick challenges to push outwards and to stop wasting effort on the wrong things which can lead to failures. This is a great example of something that I need to do for myself. Especially keeping a diary or a blog is helpful as I mentioned in the previous blog post that talked about the “Record What You Learn” apprenticeship pattern. This pattern was very true to me. Leaning from failures is important and you cannot excel at everything but accepting these limitations and learning from the failures or mistakes forces you to acknowledge them and focus on improving them so you do not make the same mistakes again.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.