Category Archives: CS-443

Capstone Sprint 2 Retrospective

This second sprint brought with it some challenges in moving to online classes for the ongoing epidemic, but with it a stronger grasp on communication and documentation using GitLab and Discord, both out of necessity and intentional effort. We have learned to better work with LibreFoodPantry workflow and are ready to go into our next sprint with our REST API, Database, and Frontend all working in isolation.

My contributions

Create file with definition of done.

Change to default .gitignore file for Spring and remove unnecessary tracked files from before we added the .gitignore,

Research internationalization support and decide that it is better to be saved once a more-final version of the front-end is complete.

Research Angular Testing and create a Spike project that covers most cases we will encounter.

Integrate ID scanner to get Student ID with an Angular component and create tests to have 100% code coverage.

Retrospective

For the first half of the sprint, we were still having weekly meetings to work together. One of our troubles last sprint was that we were discussing things in person and not doing well documenting the reasons for decisions we made. We improved on this even while having in-person meetings. By the second half, although we were all coping with changes brought on by moving to online classes, we did well in keeping each other updated and communicating through GitLab. In hindsight, it’s probably a good experience to be forced to do this. Especially if this epidemic inspires more software companies to promote working from home.

The biggest issue we had as a team was working with merge requests. There were a couple cases where code on a feature branch was not kept up to date with the master branch. As a result, there were a lot of merge conflicts to work together on resolving as a team. Overall, working through these together as a team was a good experience, because this is bound to happen when working in tandem with version control. However, now we will be reminding ourselves to pull changes from origin/master as we are working on our local branches.

We also improved with creating merge requests for each individual features, although this took a few weeks for us to all do efficiently. GitLab has a great feature where you can tightly-bind an issue to a merge request, but this caused a couple of problems for me. When the merge request is accepted, the issue is automatically closed. This messes with our workflow, because we want the issues in the “done” column, only to be closed by the product owner. Moving forward, the issues should be linked with their merge request but we will have to take care that the description doesn’t include a “Closes issue” tag.

Furthermore, when a branch is automatically made in GitLab, it creates a very verbose branch name, which is simply annoying if your Git isn’t configured to autocomplete branch names when pressing “tab”. In the future, I will create a new merge request and manually select my already-created branch. Then I will manually link the issue.

The team’s willingness to quickly meet over Discord about an issue we were having was the best thing about this sprint. In the few cases where something occurred outside of class time that required all of us, we were able to set up a time the same day or the next day and resolve the problem. This flexibility to schedule work within the sprint is what helped us get as much work done as we did.

The next sprint will involve combining our individual pieces into a working product that is capable of storing actual checkout transactions. There is a still a lot to learn and to do, but we are well on our way to finishing a viable product that we are proud of, albeit with much room to grow in the future. We will have to pay close attention in the next sprint to creating well-written documentation as we combine our API, database, and front end so that future developers can easily recreate what we’ve done and get it running.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

The Long Road

To become truly good at programming is a life’s work, anongoing enterprise of learning and practicing.Ron Jeffries et al., Extreme Programming Installed This pattern from chapter three caught my attention, the quotes they used in the beginning of this pattern were nice and  sometimes we need something to remind us that the 1000 mile journey … Continue reading The Long Road

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

The White Belt

From the blog CS@Worcester – Shams's Bits and Bytes by Shams Al Farees and used with permission of the author. All other rights reserved by the author.

Mutation Testing Blog

Hello everyone! Today I wanted to write a blog about someone else’s blog post that I found online last week while reviewing for one of my final exams. Its by James White ( https://blog.scottlogic.com/2017/09/25/mutation-testing.html ) and in his blog he talks about mutation testing, which is one of the topics we’ve covered in class recently. Mutation testing is a way to test the code that you have written by altering your code with changes that are designed with the intent of being detected by different tests you have written for your code. Basically, it mutates your code so your tests can find the mutation and, if that happens, then you know your tests worked correctly. If the mutation survives in your code then you know the tests didn’t work.

What I like about James’ blog is that he makes the idea easy to understand, and incorporates plenty of different examples to walk readers through how mutation testing works. I specifically like his example of why mutation testing is needed, and how, in his example, mutation testing was able to point out a flaw in his code that otherwise would have gone unnoticed, since you could have changed the line of code or even deleted it all together and, without mutation testing, it would have looked correct even though it wasn’t.

The other thing I liked about James’ blog is the different examples he gives of what these mutations look like. How it can change (input > 0) to (input <= 0) or how it could mutate code to check true instead of false. I also liked how he addressed the common question of how long it would take mutation testing to run, since that is a question I had myself once we started learning about mutation testing. I also thought it was pretty cool that he mentioned how mutation testing can help point out instances of redundant code, and some other neat things about it too. Overall I enjoyed reading his blog, and it helped me better understand the material we learned about in class.

From the blog CS@Worcester – Nick’s Blog by nramsdell1 and used with permission of the author. All other rights reserved by the author.

Static Testing Tools

hello, for the last time I have recently been learning about how to create application and use static testing tools. First of all I learned how to create an application with gradle. This is done by adding a few lines to the build file, the plugin for application and the path to the class with the main method. The binary to run the application will show up in the distributions folder. The next thing I learned was how to use check-style which is a tool for checking code style against a specific style sheet I used two different style sheets sun_checks and google_checks. These tools generate reports about your coding style based on the style sheet. I think these are very good for making sure you are writing clean code. The last tool I tried was spot-bugs which works similarly too check-style except instead of checking for style it checks for potential bugs and generates a report based on this.

From the blog CS@Worcester – Tim&#039;s WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Static Testing Tools

hello, for the last time I have recently been learning about how to create application and use static testing tools. First of all I learned how to create an application with gradle. This is done by adding a few lines to the build file, the plugin for application and the path to the class with the main method. The binary to run the application will show up in the distributions folder. The next thing I learned was how to use check-style which is a tool for checking code style against a specific style sheet I used two different style sheets sun_checks and google_checks. These tools generate reports about your coding style based on the style sheet. I think these are very good for making sure you are writing clean code. The last tool I tried was spot-bugs which works similarly too check-style except instead of checking for style it checks for potential bugs and generates a report based on this.

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Edge Testing

hello again, The next testing I learned was edge testing which is a combinations of boundary and equivalence. It tests to make sure each class results in the correct output and tests for errors at the boundaries. It is better in every way except one it has many times more test cases then either of the others. There are two types normal edge testing and robust edge testing. Normal only tests the valid side of each edge and robust tests the valid and invalid side of each edge.

Example with two variables x1’s edges a,b,c,d and x2’s edges e,f,g

  • Normal
  • x1: {a, a+, b–, b, b+, c–, c, c+, d–, d}
  • x2: {e, e+, f–, f, f+, g–, g}
  • Robust
  • x1: {a–, a, a+, b–, b, b+, c–, c, c+, d–, d, d+}
  • x2: {e–, e, e+, f–, f, f+, g–, g, g+}

From the blog CS@Worcester – Tim&#039;s WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Edge Testing

hello again, The next testing I learned was edge testing which is a combinations of boundary and equivalence. It tests to make sure each class results in the correct output and tests for errors at the boundaries. It is better in every way except one it has many times more test cases then either of the others. There are two types normal edge testing and robust edge testing. Normal only tests the valid side of each edge and robust tests the valid and invalid side of each edge.

Example with two variables x1’s edges a,b,c,d and x2’s edges e,f,g

  • Normal
  • x1: {a, a+, b–, b, b+, c–, c, c+, d–, d}
  • x2: {e, e+, f–, f, f+, g–, g}
  • Robust
  • x1: {a–, a, a+, b–, b, b+, c–, c, c+, d–, d, d+}
  • x2: {e–, e, e+, f–, f, f+, g–, g, g+}

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.

Equivalence Testing

hello All, after I leaned about boundary testing in class I learned about equivalence testing. Which I think does a better job at testing for correct output in a program. However it does not do as good a job of testing for edge errors like out of bounds errors and such. The idea of it is to split each variable into a range for every output. These ranges are called Equivalence classes. There are two different conditions for testing it normal/robust and weak/strong. Normal only tests valid the valid equivalence classes and robust tests the valid and invalid equivalence classes. Weak only tests each equivalence classes once and strong tests all combinations.

These are graphs of the different types

From the blog CS@Worcester – Tim&#039;s WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

Equivalence Testing

hello All, after I leaned about boundary testing in class I learned about equivalence testing. Which I think does a better job at testing for correct output in a program. However it does not do as good a job of testing for edge errors like out of bounds errors and such. The idea of it is to split each variable into a range for every output. These ranges are called Equivalence classes. There are two different conditions for testing it normal/robust and weak/strong. Normal only tests valid the valid equivalence classes and robust tests the valid and invalid equivalence classes. Weak only tests each equivalence classes once and strong tests all combinations.

These are graphs of the different types

From the blog CS@Worcester – Tim’s Blog by therbsty and used with permission of the author. All other rights reserved by the author.