Class Loading - difference between bin/ext, Script Directory, and External Jar File
v3.10.1
I seem to be having issues with the ReadyAPI class loaders, and it's probably my lack of understanding of how they work. I have a separate Groovy project in IntelliJ -- class files, etc., which compile fine. I can update methods there, or create new ones, and run tests against them within IntelliJ. And when I make such changes and return to ReadyAPI, I see ReadyAPI responding to those changes in its log.
But -- when I run the changed/new method within ReadyAPI, it will complain that there's no signature for that method, like this:
No signature of method: com.healthedge.pdm.readyapi.utils.DateUtilsForDataSource.populateRandomBirthdayForAdult() is applicable for argument types: (String, String) values: [MM/dd/yyyy, dateOfBirth]
There are 3 places in ReadyAPI to refer to external classes:
1. bin/ext
2. Preferences->ReadyAPI-> Script Library
3. Preferences->ReadyAPI->Custom Java Libraries
I've tried different options, but the one that used to work is the 2nd one, and that's what I'm using now. It seems like ReadyAPI is caching these classes and not updating when I make changes, even though it indicates that it is. I'd like to understand the purpose of these 3 options, and which one(s) should be used for what.
Any guidance is appreciated.
Never mind. There was yet a 4th location I was testing --
4. in the ReadyAPI lib directory
And I had forgotten to remove the jar file from that directory.
Doesn't answer the question of what are the functions of the 3 areas that are suggested by the ReadyAPI product and its documentation, but I fixed the immediate problem.
I think the three locations exist for better organization of libraries:
This is my suggestion on how to use them:
1. bin/ext: libraries you want to add permanently so that your tests can rely on them, e.g., JDBC driver.
2. Preferences->ReadyAPI-> Script Library: your Groovy scripts
3. Preferences->ReadyAPI->Custom Java Libraries: libraries you want to add and remove later easily via configuration, and libraries you don't want to move into ReadyAPI folders for some reason.
