Week 9 – Python Unit Testing

  • Screenshot image of your annotation left (using Hypothes.is with your login) on the document “Simple Smalltalk Testing: With Patterns“. PLEASE include a tc3045 tag in the annotation. See my example at the end of this document.
    • Note that you will need to login to Hypothes.is (Enlaces a un sitio externo.)Enlaces a un sitio externo. and most likely by using the Chrome browser with this. A previous assignment in the course had you set this up.
    • Note that this is on the WayBackMachine site. What is this and how is it important? Can you find an old (90s) version of a popular company and view that version of their website? Take a screenshot to include in your submission.

WayBackMachine is a website which periodically stores a website’s content for future revision, it can store many versions of the same page as years pass. It allows us to see how websites were before and view any information previously stored there in the case that in the future it is no longer there, or the website is no longer there, like it happened with the SmallTalk testing article.

hypothesis.PNG

 

  • Your evidence (again screenshots) of using PyCharm with pyunit.

pytest.png

  • Your evidence in the form of review/comments on the course in LinkedIn.

linkedin.PNG

Advertisements

Secret Life of Bugs

bug1

Bugs are a pain in the ass for most developers. Most of a developer’s time is probably spent fixing bugs they created themselves (if they did not create them multiply that pain by a hundred). What is very interesting is the pattern we sometimes take when solving a bugs, it is almost like the five stages of grief:

DENIAL – I CAN’T BELIEVE IT DOES NOT COMPILE
ANGER – F*CK YOU FOR NOT COMPILING, EVEN IF THAT IS MY FAULT
BARGAINING – LET ME TRY AND FIND SOME WORKAROUND
DEPRESSION -DAMN, THIS IS GONNA BE A PAIN IN THE ASS TO FIX
ACCEPTANCE – OH WELL, BETTER GET WORKING ON IT

This process can happen in a matter of minutes, hours or days, it all depends on how serious the bug is and how much time and resources we are willing to spend fixing it.

The paper The Secret Life of Bugs notes that:

  • Some bugs in the records are not bugs in strict sense.
  • Some bugs have duplicate records
  • Some bugs exhibit symptoms that are initially seen as different bugs and recorded separately
  • Some bugs do not always die when they are marked as closed
  • Some bugs basic field in the records are incorrect
  • Some bugs have wrong status.
  • Some life of bugs will never be understood without a face to face or personal investigation.

All of these factors affect how fast a bug is fixed, something in common with all these factors is that they all involve human error to some degree, and in the end, most bugs are caused by human error, mistakes in tracking bugs is also caused by human error, and how much time is spent fixing it depends on humans as well, so we better get good at bugfixing.

On Blogging

I found out after having a lot of late assignments for this class, that having to create blog after blog can be quite tedious, boring and tiresome, but after a while had passed and giving it some thought, I actually kind of enjoyed having to push blog after blog. It felt like I was creating a footprint of what I was learning and I could revisit it any time or share it with someone and tell them “HEY! I LEARNED THIS! YOU CAN TOO!”.

Of course right now most of my blogs are assignment related, but I actually kind of want to blog about other things, I just prefer to play videogames or something. However, if I ever get tired of playing League of Legends or sharing Facebook memes, I for sure will start blogging about anything I like! Sounds like a super fun idea, I am leaving my digital fingerprint on the Internet. I may die, but my blog posts will probably be stored in the internet forever, occupying space in WordPress’ servers without me ever paying a cent, FeelsGoodMan.

I really encourage anyone who doubts about bloggin to just give it a try, it is a really nice way to express yourself and I this is probably the blog I have enjoyed writing the most, because I finally am expressing what I think about blogging itself. Don’t be ashamed of posting something, just post it!

Intro to DevOps – Part 5

1. Reflect on what you already knew and what you learned in this exercise.

I actually learned quite a lot, first remembered how to create a Linux virtual machine,  I learned to use the Linux console again, learned how to write a shell script, learned how create basic a build status display for a project and a lot more, as well as how much of a hassle it can be to work with JUnit from console.

2. Much of this is simpler with already existing frameworks and services. Find ones would replace much of this work for you. What are the advantages and disadvantages of this?

I used some frameworks that helped me out with some stuff, like the Express server with Node.js, there are many Continious Integration tools out there that can help you out with these tasks, as well as some IDEs that easily run JUnit tests for you instead of having to do it from the command line.

3. Have you gained some appreciation for the concept of “excise tasks” and the value of those in our workplace that perform those as part of a team?

I indeed have, it is a pretty big task and should not be taken for granted or seen as a “lesser” task compared to “revenue programming”, since it can be just as complicated and in the end makes revenue programming less troublesome and more relaxing for developers.

Intro to DevOps – Part 4

1. Ensure that you can use your JUnit (or other unit testing) via the command line.

I didn’t install Java on part 2, so I shall do that now. After following this tutorial I was able to get Java working on my system. After installing, you can run

javac -version

to check that the installation is correct.

javacVersion.PNG

Now, we have to install JUnit to get the testing started, to do this, you can simply run this command, note that this command must be run from the folder you have your tests .java file in, or relocate it after downloading.

wget https://github.com/downloads/junit-team/junit/junit-4.10.jar

We must also download Hamcrest to the same folder for our tests to run.

After this, we create a simple test to see if JUnit is working correctly. I have decided to use the examples from the JUnit Getting Started Tutorial, which creates a Calculator class and some tests for it.

Calculator class:

public class Calculator {
  public int evaluate(String expression) {
    int sum = 0;
    for (String summand: expression.split("\\+"))
      sum += Integer.valueOf(summand);
    return sum;
  }
}

CalculatorTest class:

import static org.junit.Assert.assertEquals;
import org.junit.Test;

public class CalculatorTest {
  @Test
  public void evaluatesExpression() {
    Calculator calculator = new Calculator();
    int sum = calculator.evaluate("1+2+3");
    assertEquals(6, sum);
  }
}

I compile both classes with the commands shown below:

javac Calculator.java
javac -cp .:junit-4.XX.jar:hamcrest-core-1.3.jar CalculatorTest.java
//NOTE THAT YOU MUST REPLACE THE XX WITH YOUR JUNIT4 VERSION

Then run the tests with the following command:

java -cp .:junit-4.XX.jar:hamcrest-core-1.3.jar org.junit.runner.JUnitCore Calculator Test

junit run test.PNG

2. Setup a status page that shows the status of your build. It should be pulling from your GitHub repository on a schedule, running the unit test and then updating the status page based on web site based on build success or failure. Get creative here.

In order to show wether the build was stable or not, I created a small bash script that would compile both files, run the tests, and check if there were any failures detected in the JUnit output, and would then write “Build Stable” or “Errors found on build” onto a file.

shellScript.PNG

Then I created a server using Express which reads the buildStatus file and returns a JSON showing its content to the user at http://localhost:5555

express.PNG

statuswebbrowser.PNG

3. How could you update the README page on your repository to reflect the build status using this setup?

I could simply update the README.md instead of the buildStatus file and force a push every time tests are made or something similar, this to reflect the current project status on the repo website.

 

Intro to DevOps – Part 3

1. Ensure that you have your GitHub account.

gitprofile.PNG

2. Ensure that you have a repository created for testing.

For this I am using the repo I created in Part 2, where I created a small node server that I am going to use.initlacommit.PNG3. Setup your GitHub two-factor authentication.

This is a fairly easy step, to do, just go into your GitHub account settings > Security > Enable Two-Factor Authentication, I personally preferred to use SMS as my authentication method.

TFA.PNG

4. Setup your SSH keys so that you are able to connect to GitHub repositories using ssh.

After following these two tutorials I was able to setup an SSH key for the Ubuntu installation I am using:

Generating a new SSH key and adding it to the ssh-agent

Adding a new SSH key to your GitHub account

Inkedsshkey_LI.jpg

This allows you to interact with GitHub through SSH instead of HTTPS.

5. Ensure that you can do a git clone (use ssh) to your server from your repository. You should do this.

InkedsshClone_LI.jpg

6. Make changes to your repository (you can do this any method including via the GitHub site).

changeREADME.PNG

7. Ensure that you can update your server copy with a simple “git pull origin master” at the command line from the directory where you have pulled your data.

pullREADME.PNG

9. Automate those updates using what you learned about cron in DevOps part 2, Linux Server Setup (Individual). How often should you update? How do you ensure (and you should do this) that you do not end up with two copies of your update script running at the same time?

How often the updates should be is all dependant on what the development team has agreed to before. Usually the better changes are reflected onto the server, the better. In my case, I decided that I would check for any changes on the repo every minute.

crontask.PNG

Intro to DevOps – Part 2

This is part 2 of the Intro to DevOps, the links can be found here:

Intro to DevOps – Part 1

Intro to DevOps – Part 2

Intro to DevOps – Part 3

Intro to DevOps – Part 4

Intro to DevOps – Part 5

Install a Linux distribution – Ubuntu

I decided to do a fresh installation in a virtual machine that I had on Windows, this also helped me to remember that I had to do a swap partition (virtual RAM), which is a way that Linux uses to create some extra RAM through the hard drive.

installComplete.png

Just finished installing Ubuntu 18.04.

cleandesktop.png

I now have a clean Ubuntu installation ready to work with, I did not actually use this installation but another fresh one I installed directly on my laptop.

Install support for your development environment 

Installing Visual Studio Code

For this step instead of just installing support for certain programming languages, I decided to show how to install Visual Studio Code, which is an IDE that provides the environment for most programming languages through the use of Extensions, you still need to install some other dependencies to get some programming languages to work but installing VS Code is a good start.That’s it. Visual Studio Code has been installed on your Ubuntu desktop and you can start using it.

1.- First, update the packages index and install the dependencies by typing:

sudo apt update

sudo apt install software-properties-common apt-transport-https wget

2.- Next, import the Microsoft GPG key using the following wget command:

wget -q https://packages.microsoft.com/keys/microsoft.asc -O- | sudo apt-key add –

3.-Once the repository is enabled, install the latest version of Visual Studio Code with:

sudo apt install code

vscode.png

Installing git 

Another step for having a nice development environment is to have git installed in our system to allow us to do version control.

First, as always, we should start out by running general OS and package updates. On Ubuntu we’ll do this by running:

sudo apt-get update

After you have run the general updates on the server you can get started with installing Git.

1.-Install Git

apt-get install git-core

You may be asked to confirm the download and installation; simply enter y to confirm. It’s that simple, Git should be installed and ready to use!

2.- Confirm the Git installation
With the main installation done, first check to ensure the executable file is set up and accessible. The best way to do this is simply to run Git with the version command.

git --version

installGit2.png

Setting up web deployment

In this case I’ve decided to install Node.js as it is a very popular JavaScript runtime created to build scalable web applications.

To install it we have to run two commands:

sudo apt-get install curl python-software-properties
curl -sL https://deb.nodesource.com/setup_11.x | sudo -E bash -

After installing, you can confirm the installation with:

node -v

nodev.png

Next I created a small node server for testing and uploaded it to a repo I’m going to use later on.

serverCode.PNG

nodeServerRunning.PNG

initlacommit.PNG

Crontab setup

I do an initial crontask setup with a GitHub repo I will use later on, this task pulls from the repo every minute in order to check for changes.

crontask.PNG