Stop Skimming PDFs, Start Automating PDF Testing
On the surface, PDFs look simple, but testing them is a whole different story. Invoices, contracts, statements, compliance reports… they’re often the last thing that lands in a customer’s hands. That also means even the smallest issue, like a missing field or a misplaced decimal, can turn into something big. The challenge is that PDFs aren’t like web pages or apps where you can easily inspect elements. They’re containers packed with content, layout, images, and data from different systems. When you add in dynamic content that changes for every customer, formatting that has to stay perfect, and the regulatory risks in industries like finance or healthcare, you start to see why manual testing just doesn’t cut it. It’s slow, inconsistent, and doesn’t scale. This is where automation becomes essential. With automation, you can make sure data is always accurate, layouts stay consistent, and testing scales across thousands of documents without slowing down your team. Instead of spending hours opening PDFs by hand, QA can focus on higher-value work while still knowing that every report or statement going out the door is right. That’s exactly where TestComplete comes in. It’s built to handle the tough parts of PDF testing so you don’t have to. You can validate content down to the last character, run visual checks to keep layouts consistent, and plug it all straight into your CI/CD pipeline. The result is faster releases, fewer headaches, and a lot more confidence that the documents your customers see are exactly as they should be. Click on this link and check out a quick demo to see how TestComplete makes PDF testing easier and more reliable in action.How To: Read data from the Windows Registry
Hello all, I have recently learned how to retrieve data from the Windows registry in JavaScript test units. I am using this to return the OS information and application path information. This is very useful when added to the EventControl_OnStartTest event code. This will allow you to return OS information and other needed data at each test run. Some test management systems may provide this information for you or it may be logged in the in data produced in a pipeline run. This will embed the information directly into your test log. SmartBear KB Links: Storages Object Storages Object Methods Storages.Registry Method Section Object Get SubSection Method This bit of code will return the Product Name and Current Build from the registry. This location may vary between OS's so you will want to check this with RegEdit. let Section = Storages.Registry("SOFTWARE\\Microsoft\\Windows NT", HKEY_LOCAL_MACHINE); let regKeyString = Section.GetSubSection("CurrentVersion").Name; let productIdString = Storages.Registry(regKeyString, HKEY_LOCAL_MACHINE, 1, true).GetOption("ProductName", ""); let currentBuildString = Storages.Registry(regKeyString, HKEY_LOCAL_MACHINE, 1, true).GetOption("CurrentBuild", ""); Log.Message("Windows Version: " + productIdString + " Build: " + currentBuildString ) I have also found the need to find and set an application path and work folder in the project TestedApp for running through a pipeline because the pipeline deploys the application to a non-standard path. let Section = Storages.Registry("SOFTWARE\\WOW6432Node\\<_yourSectionName>\\", HKEY_LOCAL_MACHINE); let regKey = Section.GetSubSection(<_yourSubSectionName>).Name; let Path = Storages.Registry(regKey, HKEY_LOCAL_MACHINE, 0, true).GetOption("", ""); let WorkFolder = Storages.Registry(regKey, HKEY_LOCAL_MACHINE, 0, true).GetOption("Path", ""); let appIndex = TestedApps.Find(<_yourAppName>); if (appIndex >= 0){ if(TestedApps.Items(<_yourAppName>).Path != Path){ TestedApps.Items(<_yourAppName>).Path = Path } if(TestedApps.Items(<_yourAppName>).WorkFolder != WorkFolder){ TestedApps.Items(<_yourAppName>).Params.ActiveParams.WorkFolder = WorkFolder; } } else{ Log.Error("TestedApp " + <_yourAppName> + " does not Exist.") Runner.Stop(true); } I hope you find these links and code examples as useful as I have! Have a great day!
