Unit testing - Identify tests that can be moved to skunit_tests from sktest

[dijidiji]

Note: Posting an issue here as I ran out of space on the planner card.

There are tests that need to be run manually as part of sktest which would be good to have in skunit_tests for automated testing. Good candidates for porting over to the Catch2 unit testing format are any tests which we can write assertions to validate output. Bad candidates are tests which require a human to validate the output (such as making sure a sound plays, or making sure that an image is drawn on screen).

This could be a good set of first contributions for future students.

Status:

• test_animation.cpp​
  • Created task "Unit testing - Animation"
• test_audio.cpp​
  • Most tests already covered
  • fade_music_in/out aren't covered but just wrap backend functions, so low priority
  • download_music/sound_effect not covered but rely on an external web resource, so impractical
• test_bundles.cpp
  • Adapted existing tests (Add resource bundle unit tests and fix bug in free_resource_bundle #131)
• test_camera.cpp​
  • Wrote new tests that cover camera functions (Add unit tests for camera #123)
• test_cave_escape.cpp​
  • Mix of tests, most already covered
  • Input tests aren't covered but might be impractical to automate
• test_geometry.cpp​
  • Created task "Unit testing - Ray intersection"
• test_graphics.cpp
  • Created task "Unit testing - Save bitmap"
  • Created task "Unit testing - Clipping"
  • Hard to verify output for drawing tests
• test_input.cpp
  • Tests keyboard and mouse input, not sure how this would be done automatically. Looks mostly to be handled externally anyway (SDL)
• test_logging.cpp
  • Not sure if it's possible to verify that something has been logged
• test_main.cpp
  • Launches tests but does not contain tests of its own
• test_networking.cpp
  • Created task "Unit testing - MAC addresses"
• test_physics.cpp
  • Created task "Unit testing - Bitmap collision"
  • Created task "Unit testing - Vector"
  • Created task "Unit testing - Matrix"
• Raspberry Pi tests
  • Most of these tests require input or specific hardware for output (e.g., motors/servos). Not sure if it's possible to do these tests automatically.
  • test_raspi_adc.cpp
  • test_raspi_gpio.cpp
  • test_raspi_motor.cpp
  • test_raspi_servo.cpp
  • test_raspi_spi.cpp
• test_resources.cpp
  • Created task "Unit testing - Resources path"
• test_shape_drawing.cpp
  • Evaluating the output of drawing functions is difficult. There's an existing task on the planner board related to this (see "Investigate strategies to unit test graphics functionality")
• test_sprites.cpp
  • Sprite drawing tests are a similar situation to the shape drawing functions, mentioned above.
  • Created task "Unit testing - Sprite collision"
• TCP/UDP Networking tests
  • Created task "Unit testing - TCP/UDP Testing"
  • test_tcp_networking.cpp
  • test_udp_networking.cpp
• test_terminal.cpp
  • Unsure if we can verify terminal output
• test_text.cpp
  • Created task "Unit testing - Fonts"
• test_timers.cpp
  • Created task "Unit testing - Timers"
• test_ui.cpp
  • Interface drawing output is difficult to evaluate automatically
• Web server
  • Created task "Unit testing - Web server"
  • test_web_server.cpp
  • test_web_service.cpp
• test_windows.cpp
  • Window drawing has similar issues as interface drawing for unit testing