Build tools. Introduction to testing

IT1901 Fall 2020 - 6th Lecture

Overview

  • Administrative issues

  • Build tools

  • Testing

Administrative issues

Individual assignment 1

  • delivered project must be in the master branch

  • project needs to be named "valutakalkulator" and the packages, build files and module information need to be named consistently and reference "valutakalkulator"

  • project must build successfully and run - check that before delivering

  • .gitpod.dockerfile and .gitpod.yml - are required for gitpod support

Individual assignment 1 (cont.)

Groups

  • groups will be finalized today

  • TAs assigned to groups will be announced on Blackboard

  • work on the contract

  • choose project (domain)

  • supervision and meetings use A4-100 (Wednesdays and Fridays)

Group Deliverable 1

programmering av en enkel app, bruk av maven til bygging, og git og gitlab til kodehåndtering Krav til innleveringen:

  • Kodingsprosjektet skal ligge i repoet på gitlab

  • Prosjektet skal være konfigurert til å bygge med maven

Group Deliverable 1

  • En README.md-fil på rotnivå i repoet skal beskrive repo-innholdet, spesielt hvilken mappe inni repoet som utgjør kodingsprosjektet.

  • En README.md-fil (evt. en fil som README.md lenker til) inni prosjektet skal beskrive hva appen handler om og er ment å gjøre (når den er mer eller mindre ferdig). Ha med et illustrerende skjermbilde, så det er lettere å forstå. Det må også være minst én brukerhistorie for funksjonaliteten dere starter med.

Group Deliverable 1

  • Det må ligge inne (i gitlab) utviklingsoppgaver (issues) tilsvarende brukerhistorien, hvor hver utviklingsoppgave må være egnet til å utføres som en egen enhet. De som er påbegynt må være tilordnet det gruppemedlemmet som har ansvaret.

Group Deliverable 1

  • Vi stiller ikke krav om at dere er kommet så langt, men det må i hvert fall være noe i hvert av de tre arkitekturlagene, domenelogikk, brukergrensesnitt (JavaFX-GUI) og persistens (fillagring, men ikke nødvendigvis JSON), slik at appen kan kjøres og vise frem "noe". For at det skal være overkommelig, er det viktig at domenet er veldig enkelt i første omgang. Det er viktigere at det som er kodet er ordentlig gjort. Koden som er sjekket inn bør være knyttet til tilsvarende utviklingsoppgave.

Group Deliverable 1

  • Maven skal være konfigurert så en kan kjøre app-en vha. gradle-oppgaven run.

  • Det må finnes minst én test som kan kjøres med maven. Bygget skal være rigget til å rapportere testdekningsgrad, som derfor skal være over 0%.

  • Prosjektet skal være konfigurert for gitpod og kan åpnes i gitpod vha. gitpod-merkelappen.

  • Bruk simpleexample-prosjektet som inspirasjon, men ikke kopier kode direkte.

Build tools

Build tools (1)

  • Automate the process of building executable programs from source files

  • Packaging binaries required for deployment / distribution

  • Run automated tests

Build tools (2)

  • Build automation is a necessity to enable CI/CD

  • Remove the need to do redundant tasks

  • Improve quality of the software

    • the software builds are prepared in a consistent and predictable manner

    • possible to have data to analyze issues and improve

Make (1)

  • Designed by Stuart Feldman

  • Released in 1976

  • Uses makefiles to describe the actions required to produce the build

  • Manages dependencies

https://en.wikipedia.org/wiki/Make_(software)

Make (2)

  • Has been rewriten a number of times

  • Standard modern implementation is GNU Make

  • Used in Linux and Mac OS

Java world build tools

  • Ant with Ivy

  • Maven

  • Gradle

Apache ANT

  • modern build system

  • released in 2000

  • build files use XML

    • tends to get unmanageable even for small projects

  • Apache Ivy for managing dependencies (added later)

    • download over network

http://ant.apache.org

Apache Maven (1)

  • released in 2004

  • improves on ANT

  • build files use also XML but the structure is radically different

  • dependency management with automatic downloading over the network is available from release

http://maven.apache.org

Apache Maven (2)

  • hides complexity in build files through plugins

  • customizing is hard

  • dependency management has issues with conflicting versions of same library

Gradle

Gradle (1)

  • released in 2012

  • build scripts are written in a domain specific language based on Groovy

  • the build script is named build.gradle

  • build steps are called "tasks"

https://gradle.org

Gradle (2)

  • easy to create own tasks

  • uses plugins to hide complexity

  • applying plugins allows access to additional tasks

Gradle (3)

gradle tree

https://guides.gradle.org/creating-new-gradle-builds/

More on Maven

Maven (3)

  • manages builds, dependencies, versions

  • configuration file is pom.xml

  • has good IDE support

  • central repository(ies) for dependencies

Maven - pom.xml

  • modelVersion (4.0.0) config file format version

  • groupId - ID of group owning the project

  • artifactId - name of the final output

  • version - version of the created artifact

Maven - pom.xml (cont.)

  • dependencies - list of artifacts we depend upon

  • packaging - e.g. .jar (Java archive)

  • description

https://maven.apache.org/pom.html#Quick_Overview

Maven dependencies

  • list of dependencies

  • each dependecy has specified

    • groupId

    • artifactId

    • version (optional, good to have)

    • scope (default is compile)

Testing

Testing

  • is an important part of software development

  • a way to ensure software quality

  • automated testing allows to develop new features with a minimal effort to check if the software still works as expected

  • testing frameworks

Testing (2)

  • design

  • implement

  • write automated tests

  • run tests

  • we do not test just for know, we write tests to keep running them during project life cycle

Testing (3)

  • design tests

  • implement the test

  • provide inputs

  • run the tests

  • provide expected outputs

  • check if the result we get matches what we expect

  • produce a manageable output that the developer can consult

Testing (3)

  • design tests

  • implement the test

  • provide inputs

  • run the tests

  • provide expected outputs

  • check if the result we get matches what we expect

  • produce a manageable output that the developer can consult

JUnit

JUnit

  • Is a Java unit testing framework.

  • provides the means to automate test

  • allows to eliminate redundant testing tasks

JUnit (2)

import org.junit.*;

public class FoobarTest {
    @BeforeClass
    public static void setUpClass() throws Exception {
        // Code executed before the first test method
    }

    @Before
    public void setUp() throws Exception {
        // Code executed before each test
    }

    @Test
    public void testOneThing() {
        // Code that tests one thing
    }

    @Test
    public void testAnotherThing() {
        // Code that tests another thing
    }

    @Test
    public void testSomethingElse() {
        // Code that tests something else
    }

    @After
    public void tearDown() throws Exception {
        // Code executed after each test
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
        // Code executed after the last test method
    }
}

https://en.wikipedia.org/wiki/JUnit

TestFX

TestFX

  • testing for JavaFx applications

  • provides robots for UI testing

  • support for JUnit

https://github.com/TestFX/TestFX

Mockito

Mockito

  • mocking is a technique to test functionality in isolation

  • mock objects simulate real objects

  • return dummy values corresponding to the input given at creation

  • Mockito uses reflection features in Java to create the mock objects

https://site.mockito.org/

Jacoco

Jacoco

  • tool for assessing code coverage

  • does not need modifying code

  • can produce a report in html format

  • integrates with a number a tools including Gradle

https://www.jacoco.org/

Norwegian University of Science and Technology