-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to write tests? #97
Comments
You can use mocks or your own implementation, everything is interfaces. Just assign the public static factory to your implementation.
|
Using mocks or my own implementation is pretty much the same. I do not think this will make my extension more reliable, because it will not actually test against a concrete implementation, but against my own, where everything Burpsuite actually does has to be assumed. Wouldn't it be possible to provide a JUnit Jupiter test extension that initialises everything so that it is possible to write real tests against real implementations? |
Hi Yes, using mocks can get quite complicated quite quickly. You can find a good example of a tested extension using mocks here: https://github.com/PortSwigger/jwt-editor/tree/main/src/test/java Overall, where possible, we'd suggest splitting your own code out from Burp's native code as much as possible to test just your own functionality. Another alternative is creating a test extension you can load into Burp, which would mean you would not have to mock anything and can fully test functionality. We do have a feature request to improve the testability of extensions, so we'll add your +1 to that ticket. |
This may work for manual testing, but I would like to have automated tests.
Is this an internal ticket or can you provide a link to it? |
This is an internal ticket that we are currently monitoring. Adding +1s helps us to prioritize tickets like this in the future, as we can understand the level of interest in the functionality from the community. We do not have any plans to make any changes to the testability of extensions in the short term. |
Although not very happy with this solution, it gives the ability to write tests against concrete implementations. Writing "plain" unit tests against the Montoya API is currently not possible because the concrete implementation to those interfaces is missing and only available during runtime. See also: PortSwigger/burp-extensions-montoya-api#97 This commit provides a new Tab in DEBUG mode where tests can be run against concrete implementations during runtime. -> Semi-automated testing.
For those interested. I have implemented a workaround. Our extension now displays a separate global tab when run in debug mode. With a single click, custom test cases can be run against concrete implementations. This is done by implementing a rudimentary test framework that uses reflection to look for new test classes and methods and displays the results in a JTextPane. Reference: |
In my opinion, tests in the form of unit tests are also essential in order to write a stable extension. Unfortunately, the API does not seem to be designed in such a way that it can be easily tested. For example, it is not possible to create an HttpRequest because HttpRequest.httpRequest() calls FACTORY.httpRequest(), but FACTORY is null because FACTORY has not been initialised. It is initialised when the extension is loaded, but how do I do this in the test context?
The text was updated successfully, but these errors were encountered: