Category Archives: cs-wsu

The Clean Coder Chapters 3 & 4

In the third chapter of Clean Coder by Robert Martin, he talks more about making sure that you are clear about what you plan to do. Even though this chapter is titled “Saying Yes”, it’s more about how to make sure you can say yes and what it means to say it. A lot of this chapter is common sense and builds upon chapter 2. Basically that if you’re a professional you want to make sure you stick to the schedule you’ve set up for yourself and your team. Make sure that you stick to the deadlines that you have proposed and don’t agree to any extra work that you know you are not able to do. Also if you say you are going to finish something by a certain date, you are agreeing to be done by then and not “sort of” done. If you run into obstacles that may delay you and, in turn, the project, make sure to let your team or boss know immediately to figure out a plan. (This last part is covered in chapter 4, but feels like it should have been included with the part about commitment.)

In chapter 4, Martin discusses things that may impair your ability to code and how to deal with them. Again this chapter boils down to make sure that you take care of yourself, mentally as well as physically, and don’t ignore the fact that you work in teams or pairs. With most of this chapter, I agree with Martin. I find it hurtful for what I’m working on if I’m worried about something else or if I’m up really late at night. Since most everything you do is within a team, you don’t want to ignore them by being in “The Zone”; I know that I get rude when I tunnel vision into something. The only thing I don’t agree with is music. I sometimes find it helpful to put on music that is relaxing and has no lyrics, but when I really need to concentrate I turn it off. The last main thing that I agree with is helping one another. I have learned so much more from someone showing me how to do something or teaching someone else to do it. Programming is no longer something that is done purely by oneself, so helping and communicating to your team is an important part for one’s career.

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

Reflections Week 2

In the second week of my Software Development Capstone course, we continued on preparations for our team that would help us work on the project. The first thing that we started to do was setup a Trello account for each team member and link the board to our Slack group. This allowed us to then setup Trello so that the team could easily keep up on what everyone was doing in the current Sprint. We made it so our board had lists for “Product Backlog”, “Sprint Backlog”, “Doing”, “Done”, and “Archived Cards”. I found that working with Trello was really easy and quite intuitive for what we were using it for. Once we start the project, everyone will simply just make a card that states what they are doing in the Sprint, and then move it to the appropriate place to indicate how they are doing with it. They can even make check boxes to section out what the task involves and show how their progress is going.

After doing that, each team was instructed to go to the OpenMRS website and create an OpenMRS ID – which I had already done the first week. Once that was finished, we had to then make a short introduction post on the OpenMRS boards saying where we were from, and why were we working with OpenMRS.

The next thing that was on the list was partially setting up our environment so that we could work with Angular 2. It was suggested that Webstorm from JetBrains would work best for what we were going to be doing. After downloading that and playing around for a bit- I was familiar with IntelliJ so I didn’t spend too much time doing this – I found that several people also used PhpStorm and Atom. I decided to download them as well to look into them and see which of the three I would prefer to use for the rest of the project.

The last item that we did for the week was the (simple) tutorial found here. For the most part this tutorial was informative. I was able to understand basics of Angular pretty easily; like the syntax, different imports in Angular, how to do two-way binding, and how to make displays in Angular. However when it came to how to use Promises for data services, the basics of routing, and how to use HTTP services, this tutorial wasn’t great. There would be multiple times where I needed to look that their completed version to see where I needed to make the changes to my tutorial code because they were unclear where the lines went. Sometimes I would even have the exact same code as their working example, but mine would not show. In the end, I decided to just read what they had for the tutorial and look at how it was coded in their working example so that I understood it and didn’t confuse myself further. I think, if I were to do this again, I would just make the tutorial locally and not use the online editor they provided so that I know where the problem is.

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

Reflections Week 1

For the first week of the Software Development Capstone we mostly focused on setting up teams that we will be working with for the rest of the semester. This was done by having one person voted in as a Team Recruiter and them being able to pick who was going to be with them. After everyone had a team of six, joined our class on Slack and then created a channel for our own team. Luckily, I have had experience with slack before and know how to use it so I didn’t have to do much reading about it.

We then moved onto learning about OpenMRS and AMPATH which is the specific project we will be working with. OpenMRS is a client-server application that allows people, with no previous programming knowledge, to build a medical records system. This is so that these systems can be easily built in developing countries. AMPATH is one of these medical record systems that is based out of Kenya and helps with numerous medical needs from disease to abuse.

On the software development side of things, OpenMRS uses three languages for their application. For the OpenMRS Platform they mainly use Spring MVC and Java EE, and for their ORM they use Hibernate. With most of their front end stuff they use Angular 2. For our group project, we were told that we’d mostly be working with Angular 2 so I started reading up on some basics about it and just going through simple tutorials. (For right now I’m just reading through this tutorial, but I noticed more on other blogs and hope to get to them this weekend.) I’ve done some small things with Javascript so I’m looking forward to learning how to work with Angular 2 in this up coming project!

If anyone else is interested in learning about OpenMRS or AMPATH, here are links to their sites:
OpenMRS Main Site
AMPATH Main Site
OpenMRS Developer’s Guide

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

The Clean Coder Chapters 1 & 2

In Robert C. Martin first chapter of The Clean Coder: A Code of Conduct for Professional Programmers, he talks about what it is to be a professional. Professionalism, in Martin’s view, consists of two things: responsibility and accountability. To emphasize these aspects, Martin goes over what should be done as a programmer to make sure you’re working as a  professional. First he talks about how you should take responsibility for your code. If there are bugs, you should know about them, and take responsibility for them. You should not rely on QA to find your bugs, and apologize to them if they do find any. Make sure to always test your own code and know that it works. Also always automate your tests so that you can run them whenever they are needed. Never harm the structure of your code, but don’t be afraid to update it to make it flexible. Also keep learning for your career and not for your employer. This means take time to do task like read up on current practices, software, and anything that is relevant to your field. Also learn new languages, help people that are new to the field, and find ways to practice your expertise with other professionals. Martin also states that being a professional as means understanding humility and that means knowing when to apologize for a mistake they have made.

In his second chapter, Martin goes over why it is important to say no when you are in a professional environment. He goes over that confrontation is a part of being a professional and, if you continuously give into demands to satisfy your boss or yourself, it can lead to terrible outcomes. In this context, saying no is more to make sure that you don’t give false hope to your employer, overburden your team, and produce trash code. Martin also points out that it is better to stand up and say something about a bad situation rather than say nothing and let things fall apart.

I thoroughly agree with everything in the first chapter. This type of thinking about how to code, making sure it works, and take responsibility for what you have done has been repeated through so many of the previous classes that I’ve taken. I also agree with Martin on the fact that you should always use time outside of classes/work to practice or read up on items that are related to your career. I personally found the second chapter more relevant to myself because I have been put in a position where it would have been better for both myself and my employer to have said no. Luckily at the time I wasn’t working in the computer science field, but for a small company. The owner would continuously ask me to start jobs, which I would agree to, and then add on more work on top of that. It got to the point were I was never able to finish one project because I could not say no to the additional work they wanted done. This eventually burned me out to the point of dropping all the projects and then quitting the job. Now I know that saying no is not giving up, but making sure that you keep your projects, and yourself, on track.

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

Software Dev Capstone

This blog will be used for my Software Development Capstone that I’m currently taking. I will be making weekly posts about readings from The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin and, later in the semester, The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso.

I will also be posting about the work that I’ll be doing on the OpenMRS Project – specifically on the AMPATH Project.

-Caitlyn Lambert

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

5 Common Mistakes in Automated Testing

Original Article

In his article, Rohit Sharma goes over the top five most common mistakes users have made when using automation tools for testing.

The first item on his list is when testers “think of automation testing as little more than record and replay.” He goes on to say that proper automation testing is done when a tester has customized the generated script for their specific needs. Sharma also mentions that the record feature should only be seen as an outline and not as the finished script.

Second on the list is when testers do not validate the scripts that they are using. Sharma suggests that using checkpoints, at as many places as possible, can help to remedy this situation.

The third thing is that you don’t want to just validate your visible components when testing. Anything that happens on the back end should also be checked to make sure that your script is properly validating it (the two examples that Sharma gives are communications to a database, and making sure a file was automatically created properly).

Fourth on the list is making sure to remember that automated testing cannot replace human testing. Sharma states that “automation is a great way to augment your testing efforts,” but automation testing only works well “when you know what to look for.” In the case that he states, you could have a web page that generates unreadable text, but, unless you have someone looking out for that, you are unlikely to find it with automation testing.

The last item that Sharma talks about is making creating “inappropriate test cases.” He points out that there are multitudes of paths that a user can use in your application so trying to test all of them would waste time. Instead, try to figure out how to “condense all possible paths to a small sample of highly representative test cases,” so that it covers the majority of your user’s activity.

 

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

7 Best Practices for Agile Test Driven Development

Original Article

This article goes over seven different practices that will help with Test Driven Development when using the Agile approach.

The first thing that should be done is make sure you “avoid functional complexity.” The point of this type of approach is to keep it simple. The article suggests going over with your team to make sure that the test covers all the functionality that is needed.

The second thing is to make sure you have a clear understanding on what it is you are trying to achieve. It’s advised that you follow standard documentation and naming for your tests. This is so that developers are able to come back to it and understand what was the intended purpose for the set of tests.

The third item is that code is not overly complected. You want to make sure that your test is kept simple so that the code is easily readable and has room for any necessary improvements.

Fourth on the list is to make sure you are testing everything repeatedly. Always run tests before and after coding, and after refactoring since you never know when adding something new might break your tests. Also remember that when you refactor, to make sure that the node is still “maintainable and adheres to standards.”

Fifth point that is made is to “maintain code sanctity.” This means that you should be using version control tools to keep your code in check; which is extremely import if you have multiple developers working on the same code.

The sixth thing is making sure that your team is aware and understands how the application works. To do this make sure that the system documentation is clear and that all team members understand how the system and tests work. This will not only make sure that when new code is added, the overall program will not break, but also that new tests will work in the first run.

The last item that the article points out is to “know when to use TDD.” Test Driven Development is not suppose to be used for any testing that will take a long time. Always remember TDD primary function is to be used for projects that can be tested quickly.

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

4 Warning Signs That Your Beta Testing Process Is in Danger

Original Article

In this article, Ran Rachlin goes over the four warning signs that may signal that your current beta testing process might be in trouble.

The first point that he talks about is if your beta testing is having huge delays. The main way Rachlin says to over come this obstacle is to set strict deadlines for the team (this includes testers). He also points out to make sure that the objectives for the deadline are clear and reasonable; this is to make sure that everyone is on the same page and no one gets worried about what needs to be done. The other thing that this step includes is to make sure that constant contact is made with the testers so that communication is not lost and you receive better feedback.

The second item Rachlin touches upon is making sure that you don’t underestimate how much time it will take to go through testing. If you are on a tight deadline to get your product out, he recommends a few things that you should do. One is to make sure you have experienced tests for your product. Two is to stay in contact with the testers (as mentioned above), and inform them of the “time crunch” they are dealing with. These steps will help make sure that the testers know what they are doing before hand and are aware of the challenges they need to overcome.

The third thing is to be aware of the well being of the testers you’ve hired. If you’re testers become frustrated with the product they are working on, this can hinder the speed of testing the application. Again it helps to keep contact with the testers to make sure they are on track with the work, but you also want to make sure that they feel appreciated for the work they are doing; especially if they are in a time crunch. It may also help to give incentives near the end of a deadline to encourage testers to finish early or for a job well done. Although you should always have backup plan just in case things become too much for the testers that you have.

The last point that Rachlin makes is to ask yourself “Are we testing the target market and devices?” He says that you must make sure of two things; that you make sure the testers you have are from the target market and that you are using the “most popular devices and carriers in this target market” for your tests. If all of these issues are addressed, you should have minimal issues with they beta testing process for your app.

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

11 Things You’re Doing Wrong When Testing Code

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.

Testing IoT Devices: Key Areas

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.