MEAN-pinolla tehdyn järjestelmän yksikkötestaaminen

Abstract

Tämä opinnäytetyö on laadittu tilaajayritys Mekiwi Oy:n tarpeisiin ja siinä tutkitaan yksikkötestejä sekä niiden merkitystä ja hyötyjä MEAN-pinolla tehdyssä järjestelmässä. Tarve opinnäytetyölle ilmeni, kun sen kohteena olevan järjestelmän testausta haluttiin helpottaa ja automatisoida. Tavoitteena oli tuottaa yritykselle tietoa yksikkötestauksesta ja yksikkötestien rakentamisesta sekä suunnitella ja toteuttaa yksikkötestit kattamaan järjestelmän koko lähdekoodi.

Alusta asti oli selvää, että tutkimusta tarvittaisiin varsin vähän, sillä työn painopiste on toiminnallisuudessa. Lähteiden sisältö onkin suurimmaksi osaksi teoriapohjaa, jolla avataan tarvittavat käsitteet ja teknologiat itse toteutusosaa varten. Käytetyistä lähteistä suurin osa on kunkin käsiteltävän asian kotisivuja.

Opinnäytetyön tuloksena on kaksi sarjaa yksikkötestejä, jotka testaavat järjestelmän asiakassovelluksen käyttäjiä koskevia tietokantatoimintoja ja HTTP-rajapintoja. Lisäksi sen tuloksena saatiin tietoa tarvittavista toimenpiteistä yksikkötestien tekemisestä kattamaan koko järjestelmän koodi. Pelkkä testien kirjoittaminen ei tule riittämään, sillä sekä järjestelmän palvelin- että asiakassovelluksessa on koodia, jonka yksikkötestaaminen ilman koodimuutoksia on vähintäänkin epäluotettavaa ellei jopa mahdotonta.

This thesis was made for a company called Mekiwi Oy. The subject is to examine the purpose and benefits of unit tests in a software built with the MEAN stack. The need for this thesis arose when the company wanted to improve the testing of a software and to make it more automatic. The goal was to provide information to the company about unit testing and to design and produce unit tests to cover the whole of the software’s codebase.

It was clear right from the start that the need for research would be limited because the main focus would be on the functional side. The majority of the source material used is information about the concepts and technologies described either in the theory section or in the implementation section. The vast majority of the references are links to a homepage of the subject in question.

The end result was two sets of unit tests: one testing the database functionalities regarding users and one testing the HTTP application programming interfaces regarding users. Information on creating unit tests to cover the entire codebase was also uncovered. Mere writing the unit testing will not be sufficient because both the client and the server have code that will need refactoring to make unit testing it possible.