Skip to content

introduce unit, integration and ui tests#164

Merged
s-andrews merged 18 commits into
s-andrews:masterfrom
PeterKneale:add_tests
Sep 29, 2025
Merged

introduce unit, integration and ui tests#164
s-andrews merged 18 commits into
s-andrews:masterfrom
PeterKneale:add_tests

Conversation

@PeterKneale
Copy link
Copy Markdown
Contributor

@PeterKneale PeterKneale commented Sep 21, 2025

Hi @s-andrews, like we discussed briefly I've put together a PR introducing unit, integration and approval tests.

I tried to keep a few constraints in mind while doing this.

  • I didnt want to make any changes to the FastQC codebase itself, just introduce automated testing.
  • I didnt want to change the folder structure, just introduce the test folder
  • I used the existing ant build system, and added a script to download jars manually for now in keeping with the repo. Upgrading to gradle or maven might make dependency management a bit easier.
  • I added the new jars to the /lib folder, but didnt move the existing ones, can move those should you okay it.

In case Approval tests are a bit new I've borrowed this from the below video..They are essentially BlackBox tests that execute FastQC, capture its generated files and compare them to prevous snapshots.

Approval Test:

Java Approval Tests are a type of automated testing tool that is used to verify the correctness of a software system. They work by comparing the output of the system under test to a pre-approved "golden" version of the output. If the output matches the approved version, the test is considered to have passed. If the output does not match, the test has failed, and the team can investigate the cause of the discrepancy.

Java Approval Tests are important for software development because they help teams to ensure the correctness and reliability of their software. By automatically comparing the output of the system under test to a known good version, Approval Tests can quickly and easily identify any errors or inconsistencies in the software, allowing teams to fix them before the software is released. This can help to prevent costly bugs and defects, and can improve the overall quality of the software.

In addition, Java Approval Tests are often used in conjunction with other testing approaches, such as unit testing and integration testing. This allows teams to create a comprehensive testing strategy that covers all aspects of the software, from individual components to the overall system. This can help to ensure that the software is thoroughly tested and is ready for release.

https://www.youtube.com/watch?v=3viG9KFZ3L0

Further reading

Steps:

  • Added jUnit 5 and ApprovalTests jars to the lib folder and referenced where necessary.
  • Setup JUnit 5 targets in the ant build.xml file and verified ant clean build test works.
  • Added a wrapper for the cli so that tests can capture the output and exit code when executing the cli. See test/integration/cli
  • Added a Unit Test to validate isolated functionality.
  • Added Integration Tests to validate overall behaviour like the folder structure generated within the output zip file.
  • Added Approval Tests
    • Added two fastq files, minimal and complex to the /test/integration/data folder
    • Executed fastqc upon them via parameterised tests, capturing the fastqc_data.txt and fastqc_report.html
    • Captured the generated files, renamed them to approved then added to source control.
    • Now as changes to the source code are made, the test can be re-run, the test will fail if the newly generated fastqc_data.txt differs from those approved copies.
    • Added one date scrubber because the report date in the html will shift over time. I'll test this tomorrow and make sure that this isnt marked as a regression if i generate another report with a new date.
    • Also normalised the HTML as FastQC outputs it in a very minified form, pretty formatting makes it easier to read.

Should you like this direction, I can also look at adding tests using https://playwright.dev/ which can be used to drive a web browser like FireFox,Chrome etc to the html file and validate that each of the links work. Full browser automation is pretty straight forward these days as is adding headless chrome to a dockerised environment.

@ewels I liked your design revamp and was reading though your PR and noticed you mentioned backward compatibilty and thought this might help validate your changes too.

- Implemented HtmlContentHelpers class with methods to scrub dates from strings and normalize HTML content using Jsoup.
- Added regex pattern to identify date formats (e.g., "Fri 25 Dec 2025") and replace them with a placeholder ("Mon 01 Jan 2000"). This makes the output HTML deterministic.
- Created unit tests for the scrubDates method to ensure correct functionality.
@PeterKneale PeterKneale marked this pull request as draft September 23, 2025 00:25
@PeterKneale
Copy link
Copy Markdown
Contributor Author

PeterKneale commented Sep 23, 2025

Interesting, the inline base64 encoded png's differ slightly when run again today. Not the status icons, they remain the same, just the charts. Something is non-deterministic. The font is slightly less legible in one run than the other.

Run 1:
A1

Run 2:
A2

Diff Run 1 vs Run 2 (🔵 This image below is a visual diff of the two images above highlighting the differences found 🔵)
A1A2_diff

Base 64 diff

The status icons at the top of this diff are exactly the same base64 but the chart's base64's are all slightly different.

Base64Diff

@s-andrews
Copy link
Copy Markdown
Owner

The appearance of fonts in java depends on which font packages are installed on the host OS, and which source of java is being used. It's a bit of a pain since linux users often need to install additional OS packages to get proper functionality, even if they have the java package installed. That's probably the root of the initial differences you saw.

No idea what's going on in the one with the messed up colours!

@PeterKneale
Copy link
Copy Markdown
Contributor Author

Thanks! I was beginning to suspect as much because it was at the same time I was experimenting with installing Chrome and Firefox andI think it adjusted the fonts available.

The one will the odd colours is a visual diff just showing where the two prior images differ. It's easier than playing 'spot the difference' with two similar images.

I will see if I can stabilise the fonts available in the devcontainet and add some tests around the image generation so it's at least simpler to see what's going on.

@PeterKneale PeterKneale marked this pull request as ready for review September 23, 2025 23:28
@PeterKneale
Copy link
Copy Markdown
Contributor Author

The tests are stable within the devcontainer and I believe that will do as a stable reproducible environment for now.
Ready for review / merge @s-andrews.

@ewels
Copy link
Copy Markdown
Contributor

ewels commented Sep 26, 2025

This looks really nice @PeterKneale!

What do you think about adding a GitHub Actions workflow that runs the tests for pull_requests, and pushes to master?

Could tie in nicely with #156 👀

@PeterKneale
Copy link
Copy Markdown
Contributor Author

Yes absolutely - I saw your work on that and its definately the right direction.
I thought initially I would keep this PR functionally isolated to just adding tests as I'm new to the project and didnt want to step on toes. Happy to add the workflow though, can work on it today, or just add it in the next pr.

Also I found that its possible to render individual ui components to a PNG for use in approval tests which looks quite useful.

I'm working my way through a pipeline making sure I really understand the tools i'm using and will be taking a look at your test data for multiqc soon too - very nice product by the way!

@PeterKneale
Copy link
Copy Markdown
Contributor Author

@ewels done

…all types of tests can use the same test data set.
- Added missing dependencies to the postCreateCommand in devcontainer.json.
- Renamed 'quick' to 'fast' in TestCases.java for consistency.
- Created a new readme.md file for tests, detailing test data usage and running instructions.
@PeterKneale
Copy link
Copy Markdown
Contributor Author

PeterKneale commented Sep 27, 2025

The ui test automation looks to be working well in the devcontainer.

Its good to see my tiny hand typed fastq files being rendered out nicely.

  • The simplefastq scenario has one sequence of 16 bp:
BasicStatsTest testRendering minimal Linux approved
  • The complex fastq scenario the other has 5 sequences of 16bp making a total of 80.
BasicStatsTest testRendering complex Linux approved

@PeterKneale PeterKneale changed the title introduce unit, integration and approval tests introduce unit, integration and ui tests Sep 27, 2025
@PeterKneale
Copy link
Copy Markdown
Contributor Author

PeterKneale commented Sep 27, 2025

@s-andrews @ewels
The framework is in place now to add most types of tests. Visual regressions, which Simon mentioned are problematic, should be minimised by having approval tests in place for both the html report and the gui.

It was interesting finding out that I can render out individual dialogs to png files which made adding the approval tests easy.

I dont understand the bioinformatics like you guys but the above two screen shots of the basic stats module have what I understand to be the right numbers of sequences / bases / lengths etc.

@s-andrews s-andrews merged commit 29c8f8b into s-andrews:master Sep 29, 2025
@PeterKneale PeterKneale deleted the add_tests branch October 1, 2025 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants