Episode #18 – The journey of 1000 miles starts with a single step ...... Unit Testing

Date: 1/12/2020

Guests: none

Welcome and greetings

Recap of last episode

• In the last episode, we discussed Test Automation and how it can be used to accelerate your pipelines. We also discussed some of the methods of automating tests and some products that can help you with your automation.

Summary of this episode

• In this episode, I’m going to discuss the lowest level of testing possible by a developer, and that is Unit Testing. I’m going to give a brief description of what it is, what value or benefits that it can bring to the table, when to start it, and some examples of how it can be implemented.

What’s in it for you?

• After listening to this episode, you should have a better understanding of what unit testing is, how it is different from other types of testing and how it can be used to speed up some of your development efforts.

Episode Content

• What is it?
  • Unit Testing is when a developer writes tests to validate the smallest piece of code possible.
    • Methods, functions, procedure calls, etc.
  • A Unit is a self contained piece of code that typically has a small number of inputs and outputs.
  • A Unit Test can have constructor and destructor methods to ensure that any needed data or structures are created before the test is run and cleaned up once the test is done.
• What benefits does it provide?
  • Testing smaller pieces of code is faster than testing the whole program.
  • Tests are simpler since they cover a smaller set of code.
  • Defects found in unit testing are cheaper to fix since the change should be smaller.
  • Debugging defects found in unit testing is faster due to the smaller set of code to review.
• When should I start using it?
  • When you write the first method, function, procedure call.
  • You should write your unit test cases in tandem with your program code.
  • The earlier the better.
  • It is one of the predecessors of Test Driven Development.
• What can it be used with?
  • Any of the modern programming languages should have their respective unit testing framework. Java has Junit, c variants have xunit, python has pytest…..you get the picture.

• How to use it? A real life example for Java (kind of)
  • method call

public int addNumber(int x, int y) {

return x+ y;

}

• Unit test

public void testAddNumber() {

double result = addNumber(2,3);

assertTrue(result == 5)

}

• Unit Tests are grouped into TestSuites
• Test Suites are executed by TestRunners
• Test Suites are classes that contain a grouping of individual Unit Tests that relate to a specific Java class that you are developing.
• TestRunners are classes that are written to consume the Test Suites, execute any test cases found in the TestSuite class, and raise the result for the entire run of the TestSuite.
• There are several different types of frameworks, Junix, xunit, pytest, mockito.
  • You should choose the one that is appropriate for the program that you are developing.
• Each framework while similar, has its own syntax and procedures.
• How to get the most out of your Unit Testing?
  • Pick the framework that is designed for the language that you are working with.
  • Keep the test unit as small as possible (single method or function).
  • Run your Unit Tests often – faster feedback is better.
  • Update your Unit Test Cases as changes are made to your codebase. Don’t wait until the end to write new Unit Tests or update existing ones.

Recap of this episode

• In this episode, I discussed unit testing, how it benefits developers and development efforts, and examples of how it can be implemented.

Like me Like my podcast – share, like, thumbs-up, review, subscribe

Next Episode: Family Feud - Component Integration Testing

Episode #16 – Testing 1,2,3

Episode #16 – Testing 1,2,3

Date: 1/5/2020

Guests: None

Welcome and greetings

Recap of last episode

• In the last episode, we talked about the need to start your testing early in your Software Development Life-cycle (SDLC) where it is cheaper to remove defects that are found. We also discussed some of the reasoning by why you need to start early testing, some types of early testing, and costs of early testing…..or starting early.

Summary of this episode

• In this episode, I’m going to discuss some of the different types of testing and where they typically fit into your SDLC.

What’s in it for you?

• After listening to this episode, you should have a better understanding of the types of testing that are typically seen in a SDLC and what they are composed of.

Episode Content

• Requirements review
• Unit Testing – testing of a specific piece of code. This is a test for the smallest functional piece of code. Think of this as testing a specific function or method.
• Component Testing – This is used to test the complete functionality of a class. All of this testing should be stand-alone and only involve the functions and methods of this class. It can be thought of as method a calls method b and passes a defined set of data and expects method b to return a defined response (data, true/false, etc.).
• Component Integration Testing – This consists of testing how the components of your application interact with each other. It can consist of passing a specific set of data between the functions in your class to ensure that they output of the class meets the defined criteria.
• System Integration Testing – This testing is usually performed when your application is deployed to a defined testing environment. The environment should have all the infrastructure, middle-ware, and data to support your testing. This type of testing is used to evaluate how your application interacts with external entities. It could be a call to another application or website, a call to an internal company API (Application Programming Interface), or writing to an external database for logging. This type of testing can be very extensive and time-consuming if it is done manually.
• User Acceptance Testing – This testing is done after you have deployed your application to a stand-alone environment and your business users are the only ones that are allowed to test against it. They should be trying to determine if the application or changes meet the needs as outlined in the business requirements (remember when we said the easiest type of test was a requirements review).
• Regression Testing – this is a defined set of tests that are run every time that a change is made to an existing application.
• Smoke Testing – This is a sub-set of your regression test suite that can be run around a specific change to ensure that the application is performing as expected.
• Non-functional Requirements
  • Performance Testing – uses a defined load against the application (ex. 100 http sessions started per second)
  • Load Testing – tries to determine how the application will work under a higher than normal load or usage.
  • Break Testing – ramps up the load until the application breaks. This is done to determine what your real capacity is for the infrastructure that you have set up for your testing (ex. 1 web server can handle 1,000 http sessions per second). Then you can use that to extrapolate how much infrastructure that you will need for your expected production capacity.
  • Spike Testing – This testing tries to determine how your application will handle unexpected spikes in traffic. Will the application continue as normal, will it slow down, or will it stop working and crash unexpectedly.

Recap of this episode

• In this episode, I discussed various types of testing and where they are typically found in the SDLC. This is not an all encompassing list and does not dive too deeply into each type but is a general overview of how they can be used and how you might want to think about using them to testing your applications.

Shout-outs- Mike Lyles and his new book – The Drive Thru is NOT Always Faster

Like me Like my podcast – share, like, thumbs-up, review, subscribe

Next Episode: Test automation