Week 9 – Python unit testing

pytest evidence:pytestevidence

The course in lynda is quite useful to understant not only pytest implementation but the way a TDD developer should think, the best practices, asserts statements and, in a nutshell, it is an step by step tutorial of how to do TDD, however, it has some improvement opportunity, for example, there are blank spaces in which the creator does not speak at all.

Evidence of hypothes.is comment:

hypoth-01

 

 

 


(EXTRA) Way back machine:

this is how it all started for facebook:

fb01

Photo taken on August 6, 2005

fb02

Photo taken on August 28, 2005



fb03

Photo taken on December 27, 2007

fb04

December 05, 2008

fb05December 31, 2012

I really enjoyed watching Facebook landing page evolve, who would think that the website with this landing page would become one of the most visited sites of the world. fb01

 

 

 

 

 

 

DevOps part III: Github, SSH and keys

 

  • Ensure that you have your GitHub account.

ensuringExistanceOfGithubAcc

https://github.com/OscarSierra24

 

  • Ensure that you have a repository created for testing. I recommend some form of web content, but you can choose your content for the testing. You should put this in the root of your web server that you created in DevOps part 2, Linux Server Setup (Individual)

repo

https://github.com/OscarSierra24/software-testing-hw

 

  • Setup your GitHub two-factor authentication.

two-factor-enabled

github-ssh-keysssh

ssh-test

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

clone-via-ssh

  • Make changes to your repository (you can do this any method including via the GitHub site).
  • 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.

git-pull

  • Does the webpage update if you reload that this code sits in?

YES.

  • 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?

Ideally, we should update our local master branch (git pull origin master) whenever there’s a push to the remote.

I have heard and read about jenkins and git hooks as the best way to do this, however, since the goal is to implement this with cron, I decided to create a cronjob that pulls every minute.

As we can see. It works, I added the file ignore-this-im-just-testing-cronjob.txt via the github site

Since cron is doing the pull request on the background, I didn’t have to pull to get the remote changes.

cronjob

 

 

DevOps part 2, Linux Server Setup

These are the evidences of accompishing the devOps part2 activity:

Intro to DevOps

Methodologies has been studied due to the high pressure that teams have while developing (they are pressured with time, quality, security, etc). One of many problems that had been spotted was the lack of communication between different departments inside one company, while trying to solve this problem DevOps emerged.

devops

DevOps is a process that represents the fusion of the operations and the software development team in a single team, it primarily seeks for techniques that facilitates the development process with businesses needs to generate shorter software life cycles.

But more briefly, DevOps is about a mindset change.

some of the DevOps principal practices are:

  • automated configuration management, testing and application deployment
  • Version control of application and infrastructure code to enable collaboration and rollbacks
  • CI (continuous integration) to automate code builds and enable faster feedback and iteration through more frequent, lower risk releases.

There is a common misunderstanding that says that DevOps should be part of the job title, but that is not the case, DevOps changes the communication inside the company, it means that it is a cultural change not a modern job position.

@skillsmatter #codenode #devops

osde8info – devops

References

Ver en Medium.com

https://aws.amazon.com/devops/what-is-devops/

What Is DevOps?

https://m edium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0

 

The secret life of bug

The creators of «The secret life of bugs: Going past the errors and omissions in software repositories» noticed that researchers cared a lot about repositories histories as the sole evidence of the software development process, but they questioned if doing this was correctly, considering that there is a lot of things going on that are not recorded on those histories.

To gather information, they studied random Microsoft bug cases.

There were two approaches to study these cases, one of them studied the bug history and the other checked with surveys if the conclusions of the first approach were right by asking professionals in charge of the studied projects.

The study conclusions determined that, electronic records are not trustworthy, there is incomplete information that could mislead actual facts.

My personal thoughts about this is that it is very difficult to have a correctly bug record because you can’t register every effort that each team member made (which translates to knowledge that potentially leads to the solution of the problem), their conversations, experiences and personal activities also helped in the bug solving process and they would not show up in those records.

References

Aranda. J et al. The secret life of bug: Going past the errors and omissions in software repositories. Retrieved from https://plg.uwaterloo.ca/~migod/846/papers/aranda-secretLifeofBugs.pdf

Unit Tests

Hi everyone, this post is to let you know how can you use JUnit to test your java code inside the eclipse editor. I am going to assume that you have already installed eclipse and can execute correctly a hello world program.

  1. Create a new java project (which from now on I am going to call MyProject)
  2.  Right click on the java project and go to properties.
  3. Inside the Properties for MyProject window go to Java Build Path >> Libraries >> select ModulePath >> Add Library and select JUnit.
    • By adding this, you are now going to be able to import the JUnit package inside your project.
  4. Now we need to create a JUnit test case, so, in the package explorer, right click on MyProject >> new >> JUnit Test Case and a New JUnit Test Case window will pop up over there you must select which JUnit version you want to use, the source folder, the package name and so on… Click on finish whenever you want.

Coding Example:

As mentioned in the previous blog, I am going to begin with the test cases.

We are expecting to have a method that properly checks if a string that represents a new username is syntactically right according to the following rules:

  • The username must be within 5 – 20 character length
  • The username can not contain numeric characters
  • All the characters must be lowercase

By having those rules, we can now start coding the expected behavior with some test cases.

To avoid writing an infinite amount of tests to see that our code is behaving properly we might want to select the test cases that will help us test each of the rules, this will grant us that each of those rules are being obeyed and if not, will help us see in which one it is failing.

So, let’s divide the problem:

  • The username must be within 5 – 20 character length

-∞ —REJECT— 5 —–ACCEPT——- 20 ——————-REJECT—————— ∞

1.- username with length of 20 must be accepted:
username = «abcdefghijklmnopqrst»;
assertEquals(true, test.validateUsername(username));

2.- username with length of 5 must be accepted:
username = «abcde»;
assertEquals(true, test.validateUsername(username));

3.- username with length of 0 must be rejected
username = «»;
assertEquals(false, test.validateUsername(username));

4.- username with length of 25 must be rejected
username = «abcdefghijklmnopqrstuvwxy»;
assertEquals(false, test.validateUsername(username));

  •  The username can not contain numeric characters

5.- username with one number must be rejected
username = «abcdefghi1»;
assertEquals(false, test.validateUsername(username));

  • All the characters must be lowercase

6.- username with uppercase letters must be rejected
username = «1bcA»;
assertEquals(false, test.validateUsername(username));

And now, after writing our test cases, we can write our method considering all those cases:

public boolean validateUsername(String username) {
if (username.length() < 5 || username.length() > 20) {
return false;
}
for(int i = 0; i < username.length();i++) {
if(Character.isDigit(username.charAt(i))) {
return false;
}
if(Character.isUpperCase(username.charAt(i))) {
return false;
}
}
return true;
}

Finally, we run the test cases and see if one of them fails

https://github.com/OscarSierra24/Software-testing-junit-homework

Kent Beck Audio

I have always done unit testing (even prior to knowing its existence), it just feels natural to test every single part that is going to be assembled with others to do a job. However, I am more used to coding first and then thinking about the test cases that my code should pass in order to say that it works properly.

Difficult choice.

Evaluating.

After reading about TDD, I believe that it is worth giving it a chance, since it makes sense to first think about the edge cases that your code will face to prevent avoiding a solution to them. Also, gathering the requirements before starting to code is a must, and TDD forces you to do so. And this is what makes a lot of sense, by doing this, you are supposed to make sure that the tests covers all the requirements given before writing a single line of code, this means you already will have in mind everything you need to avoid (or to keep a track on) while coding the solution.

hellyeah designer flowchart
Design’s importancy.

To be honest, I don’t remember a time when I have started by creating the test cases, but I will definitely give it a try.

Nevertheless, I kind of see some problems with this, TDD works only when you already are aware of all the requirements of your code and, as sad as it sounds like, this does not happens always. Additionally, real world scenario happens, for example, in my work, we create software for other organizations, so, maybe in a perfect day we gather all the requirements that our client really requires for the project. They are expecting to see progress within a month, the month passes, they see the project progress and then they start requesting changes, now some previous requirements are no longer requested and new requirements have come, this constant change will not let us do the TDD development process correctly.

About what should I learn next regarding this topic, I think this is a question that could have been made before and a lot of answers have come, by reading more about TDD in internet forums I am going to understand the best fit solution to this situation or, at least, I will learn about other people experiences and create different solutions according to each specific situation.

Diseña un sitio como este con WordPress.com
Comenzar