Closed (fixed)
Project:
FillPDF
Version:
5.0.x-dev
Component:
Code
Priority:
Major
Category:
Plan
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
3 Jan 2012 at 20:42 UTC
Updated:
6 Apr 2022 at 21:04 UTC
Jump to comment: Most recent
See child issues.
---
Original description
The time has come to start writing tests for this module to ensure that it remains stable as new features are added. This was inspired by #1355090-1: Improve variable include for webform.submissions.inc.
Start with: #1877590: Write test base
Initial tests I see as being needed are (create issues for these, me or anyone):
- Ensure exporting and importing PDF configurations works
- Ensure transforming field values prior to sending them to the PDF works on the global and field levels, and that field settings take precedence over the global ones
- Ensure both a node and a webform can be filled in and that all valid link parameters for each do the right thing (e.g. sid included or omitted for Webform submission, multiple nids, etc.
- Test that access checks work correctly, particularly for the Publish Own PDFs permission.
- Although the underlying parsing and filling implementations are tested by PDF Forms API, this module still needs tests that parsing and merging works. Probably a simple test of doesn't-return-nothing will suffice because PDF Forms API checks that the actual operation is correct.
This is a meta issue, so these ideas need some more refining. Corrections and suggestions are welcome. These will be for 7.x-2.x. Backporting may happen in the future if others provide patches or sponsor it.
Comments
Comment #1
wizonesolutionsWould really love to look into this during camp. Especially after I cut another broken release recently.
Comment #2
wizonesolutionsRemoving redundancy.
This is coming soon since I have recent experience writing tests and understand better how to do this.
Comment #3
wizonesolutionsBumping this. I'm focusing exclusively on test coverage for this and PDF Forms API until they have at least decent test coverage. It is time.
Comment #4
wizonesolutionsDe-tag.
Comment #5
wizonesolutionsFortunately, some of the tests have been offloaded to PDF Forms API now. That makes getting a base level of tests going for Fill PDF easier. Updated issue summary accordingly.
These tests are next in my radar, and then refactoring and new features!
Comment #5.0
wizonesolutionsUpdated issue summary.
Comment #5.1
wizonesolutionsUpdated issue summary.
Comment #5.2
wizonesolutionsUpdated issue summary.
Comment #5.3
wizonesolutionsUpdated issue summary.
Comment #6
wizonesolutionsUpdating to target 8.x-4.x.
Comment #7
wizonesolutionsComment #8
wizonesolutionsComment #9
wizonesolutionsComment #12
wizonesolutionsAlright. I don't want to create too many child issues (because let's be honest, it's unlikely anyone else is writing these). I've broken up the tests into their two major areas, and those are my goals for the first pass. After that, new features will be accompanied by tests.
Most tests will be integration tests. Maybe all, just because it's easier. Going to try for unit tests on services though since I've been good about providing interfaces, and most of the service methods don't rely on too much information.
Comment #13
wizonesolutionsI'm tagging this as needing an issue summary update. It's not a perfect tag, but basically I just need to go through and re-evaluate what actually remains here. We have gotten a lot of tests since when I opened this.
Comment #14
liam morlandComment #15
liam morlandThere are a reasonable number of tests now. Any new features or bugs fixed should have tests written at the time. I don't think a separate tests ticket is needed at the moment.