Software Testing Overview — Unit Testing

Photo by Sigmund on Unsplash

Any test is composed of 3 parts:

  1. Prerequisites that are needed
  2. The expectation of what the result should be
  3. Trigger to make the call that will be tested

A rough example using RSpec — A testing library for Ruby

subject { described_class.process(data: data) }
let(:id) { 123456 }
describe '#process' do
context 'when everything is going well' do
before
allow(ExampleClass).to receive(:process).with(id: id).and_return(true) # Mocking here that the method return true
end

it 'returns true' do
expect(ClassMethod).to call(:process).once # Expectation that it should call the service once
subject // Trigger
end
end
end

Mock things are with the “allow” keyword, while the “expect” keyword is for what you are going to check.

Unit Testing

Unit testing is important, if you don't learn it right at the beginning then it is harder to change later and code can become overcomplicated.

Unit testing is testing a file completely separate from the rest, even if you have dependencies, they can be mocked.

Basically, the bottom stack means tests should be isolated, and usually, they run faster, so most of the testing should be done on Unit Test (that's why the piece is bigger) and as you move to the top, things should be tested at a smaller level, because they require more integration with dependencies (databases, external APIs, etc) and for that reason, they are slower to run.

So, we should do have integration tests, but we don't have to do integration tests for everything… because we don't need to actually have something created on the database to test your stuff, we can just mock it and that way saves some time and test properly what would happen. Of course, that is doing the assumption that the external calls call your files have been properly tested. If they have been unit tested properly, then we don't need to make that call, because it has been tested to be working fine, and that's why we mock it instead of letting the call go through.

Photo by Scott Graham on Unsplash

The Practical Test Pyramid

https://martinfowler.com/articles/practical-test-pyramid.html#TheTestPyramid

Continuous delivery, a practice where you automatically ensure that your software can be released into production at any time, can help you deliver your software faster without sacrificing its quality.

With continuous delivery, you use a build pipeline to automatically test your software and deploy it to your testing and production environments.

Automating everything — from build to tests, deployment, and infrastructure.

Test Pyramid

Testing Three Layers:

  1. Unit Tests
  2. Service Tests
  3. User Interface Tests

Testing Rules:

  1. Write tests with different granularity
  2. The more high-level you get the fewer tests you should have

Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end.

Unit Tests

The foundation of your test. Your unit tests make sure that a certain unit (your subject under test) of your codebase works as intended, and a unit test class should at least test the public interface of the class.

Simply stick to the one test class per production class rule of thumb and you’re off to a good start.

Don’t reflect your internal code structure within your unit tests. Test for observable behavior instead. Think about:

if I enter values x and y, will the result be z?

Unit Test When Refactor Codes

With refactoring, you don’t change what your software does, you change how it does it. It improves the structure of code without changing its external behavior.

If the refactoring does not change the public interface, then you leave the unit tests as is and ensure after refactoring they all pass.

If the refactoring does change the public interface, then the tests should be rewritten first. Refactor until the new tests pass.

  1. identifying at what level that behavior will remain the same
  2. that the interface driving that behavior will remain the same
  3. start putting in tests at that point.

Test Structure

  1. Set up the test data
  2. Call your method under test
  3. Assert that the expected results are returned

“Arrange, Act, Assert”“given”, “when”, “then” triad, where given reflects the setup, when the method call, and then the assertion part.

Integration Tests

All non-trivial applications will integrate with some other parts (databases, filesystems, network calls to other applications). When writing unit tests these are usually the parts you leave out in order to come up with better isolation and faster tests. Integration Tests test the integration of your application with all the parts that live outside of your application.

  1. start a database
  2. connect your application to the database
  3. trigger a function within your code that writes data to the database
  4. check that the expected data has been written to the database by reading the data from the database
  1. start your application
  2. start an instance of the separate service (or a test double with the same interface)
  3. trigger a function within your code that reads from the separate service’s API
  4. check that your application can parse the response correctly

Contract Tests

Microservices — Splitting your system into many small services often means that these services need to communicate with each other via certain interfaces.

  • REST and JSON via HTTPS
  • RPC using something like gRPC
  • building an event-driven architecture using queues

For each interface, there are two parties involved: the provider and the consumer:

  • The provider serves data to consumers.
  • The consumer processes data obtained from a provider.

In a REST world, a provider builds a REST API with all required endpoints; a consumer makes calls to this REST API to fetch data or trigger changes in the other service.

In an asynchronous, event-driven world, a provider (often rather called a publisher) publishes data to a queue; a consumer (often called a subscriber) subscribes to these queues and reads and processes data.

UI Tests

UI tests test that the user interface of your application works correctly. User input should trigger the right actions, data should be presented to the user, and the UI state should change as expected. Test for usability and a “looks good” factor you leave the realms of automated testing.

End-to-End Tests

End-to-End Tests test your deployed application via its user interface which requires a lot of maintenance and running pretty slowly.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Hanwen Zhang

Hanwen Zhang

21 Followers

Full-Stack Software Engineer at a Healthcare Tech Company | Document My Coding Journey | Improve My Knowledge | Share Coding Concepts in a Simple Way