Successfully reported this slideshow.

SoapUI Pro Plugin Workshop #SoapUIPlugins

1

Share

Upcoming SlideShare
Testing soapui
Testing soapui
Loading in …3
×
1 of 37
1 of 37

SoapUI Pro Plugin Workshop #SoapUIPlugins

1

Share

Download to read offline

Ole Lensmar, CTO of SmartBear Software, explains how to develop your own plugins for SoapUI Pro, the world's most popular API testing tool. #SoapUIPlugins

Ole Lensmar, CTO of SmartBear Software, explains how to develop your own plugins for SoapUI Pro, the world's most popular API testing tool. #SoapUIPlugins

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

SoapUI Pro Plugin Workshop #SoapUIPlugins

  1. 1. SoapUI Pro Plugin Workshop #SoapUIPlugins
  2. 2. WHY CREATE A SOAPUI PRO PLUGIN?
  3. 3. Plugin Scenarios  Integrate with other tools, platforms or technologies  Tailor functionality for specific APIs  Add new functionality for existing protocols  Add new protocols
  4. 4. Business Scenario  Target SoapUI Pros 40000+ paying customers  Plugin authors can charge for plugins in any way they want  SmartBear is planning a plugin “Marketplace” to help promoting and monetizing  Plugins can be promoted to all existing SoapUI and SoapUI Pro users (> 1 million) from within the tool  Join the ranks of Mulesoft, Swagger, Apiary, etc.
  5. 5. How are plugins distributed?  Via SmartBears Plugin Repository – Available from inside SoapUI Pro – One-click download and install  Commercialization and Licensing up to the plugin author  Can be distributed as standalone files also
  6. 6. How to Submit Your Plug-in Idea • Build Your Plug-in • Email Your Extension to soapuiplugins@smartbear.com with the following: • Plugin Name • Description • Creator • URL to read more • IMPORTANT: remember to change the extension first! We’ll change it back to .jar for you. • First 50 submissions will receive a T-shirt
  7. 7. PLUGIN INTERNALS
  8. 8. What is a plugin technically?  A single JAR file that contains – Plugin functionality – 3rd party libraries  Plugins are easiest written in Java or Groovy  Building and packaging easiest with Maven  Plugins are distribute either via the integrated repository or as standalone files
  9. 9. A plugin can contain  Actions - that users invoke via menus/toolbars  Listeners - that are triggered for specific events happening in SoapUI Pro  Factories : that add – UI objects (editors, inspectors) – Testing objects (TestSteps, Assertions) – Miscellaneous behavior  Any combination of the above
  10. 10. Plugin Annotations  Plugin classes are “marked” with corresponding Java annotations  When SoapUI Pro loads a plugin it looks for these annotated classes and configures them accordingly  Annotations exist for each possible extension point (Actions, Listeners, Factories, etc)
  11. 11. The @PluginInfo annotation  Provides plugin metadata  All plugins need to have one @PluginInfo annotated class @PluginConfiguration( groupId = "com.smartbear.plugins", name = "testplugin SoapUI Action", version = "0.1”, autoDetect = true, description = "testplugin SoapUI Action”, infoUrl = "" ) public class PluginConfig extends PluginAdapter {}
  12. 12. GETTING STARTED Languages and Tools
  13. 13. Tools  Java Editor or IDE (like Eclipse or IntelliJ IDEA)  Maven build tool  SoapUI Pro (trial will work fine)
  14. 14. Creating an empty plugin project Generate: mvn archetype:generate -DarchetypeGroupId=com.smartbear.maven.archetypes -DarchetypeArtifactId=soapui-plugin-archetype - DarchetypeCatalog=http://www.eviware.com/repository/maven2 Prompts for name, package, version, language and type (lots more on that later) (Read more: https://github.com/olensmar/maven-soapui-plugin-archetype)
  15. 15. Build and install  The archetype creates a working plugin skeleton  Build the plugin with mvn clean:install  The .jar file in the target folder is your plugin!
  16. 16. Packaging 3rd party libraries  Need to be added to the created jar in a “libs” folder  Automate this with the maven assembly plugin  Have look at the sample plugins on GitHub  Build with mvn assembly:single  SoapUI Pro will automatically unpack and add jars to plugins classpath
  17. 17. PLUGIN TYPES I know this is tedious – but I want to show you all the possibilities
  18. 18. Plugin types – Actions  Action: creates an Action, by default at the Project level  @ActionConfiguration annotation specifies; – actionGroup: which popup menu (see ActionGroups class added by archetype) – toolbarPosition: which toolbar to show in – beforeAction/afterAction: position in menu/toolbar – iconPath / toolbarIcon: icons to show – keyStroke: keyboard shortcut – description: (used for tooltip) – separatorBefore/separatorAfter: adds surrounding separators  Annotated class must implement “SoapUIAction” interface – The “perform” method is called with the selected object when invoked  Use to add any kind of user-driven functionality
  19. 19. Plugin types – Discovery  Discovery: creates a custom REST Discovery method  @PluginDiscoveryMethod – no annotation properties  Annotated class must implement “DiscoveryMethod” interface  APIs can be discovered asynchronously  Invoked from “New Project “ dialog
  20. 20. Plugin types – Import  Import: creates a custom Project Importer  @PluginImportMethod – no annotation properties  Annotated class must implement “SoapUIAction” interface  For new ways of importing APIs – for example an external API file format  Invoked from “New Project” dialog
  21. 21. Plugin types – PanelBuilder  PanelBuilder: creates a PanelBuilder for a SoapUI object  @PluginPanelBuilder – targetModelItem property; the object class for which panels can be built  Annotated class must implement “PluginBuilder”  Used for building Desktop and Overview panels (main and bottom left)  Main use case: Create panels for custom TestSteps – Secondary: Overriding existing panels
  22. 22. Plugin types – Prefs  Prefs: creates a custom tab in the global Preferences  @PluginPrefs annotation – no properties  Annotated class must implement “Prefs” interface  Shows up as a tab in the Global Settings dialog  Use it for managing global settings related to your plugin – Project-specific settings are better managed via a custom Project action
  23. 23. Plugin types – Editors Views  RequestEditor/ResponseEditor: create a custom Editor view  @PluginRequestEditorView / @PluginResponseEditorView annotations – viewId property; name of the View  Annotated class must implement “EditorView” interface  Adds custom editor tabs to request/response message editors  For new message formats, specific APIs, etc.
  24. 24. Plugin types – Editor Inspectors  RequestInspector/ResponseInspector: create a custom Inspector tabs  @PluginRequestInspector, @PluginResponseInspector annotations – inspectorId property; name of the inspector  Annotated class must implement “EditorInspector” interface  Adds inspector tab to request/response message editors  For editing custom aspects of a request, for example together with a custom RequestFilter or RequestTransport
  25. 25. Plugin types - TestSteps  TestStep: creates a custom TestStep  @PluginTestStep annotation, properties: – typeName : internal id to uniquely identify this type of TestStep – name: a verbal name of the type of TestStep – description: description of what it does – iconPath: an icon to show in the toolbar (optional, but recommended)  Annotated class must implement TestStep interface (usually extends WsdlTestStepWithProperties)  Adds a new TestStep to be used with functional tests  Usually combined with a @PluginPanelBuilder for providing views
  26. 26. Plugin types – Assertion  Assertion: creates a custom assertion  @PluginTestAssertion annotations, properties; – id: unique identifier for this type of Assertion – name: name for the type of assertion – description: a description of the assertion – category: which category the assertion belongs to • Available categories defined in AssertionCategoryMapping  Implementing class needs to extend WsdlMessageAssertion and implement RequestAssertion or ResponseAssertion (or both)  Adds a new Assertion for asserting request or response messages during functional and load tests (and soon MockServices as well)
  27. 27. Plugin types - RequestFilter  RequestFilter: creates a custom Request filter  @PluginRequestFilter annotation – protocol property defines which URL protocol to apply to  Annotated class must implement “RequestFilter” interface  For modifying incoming/outgoing messages, for example; – Add tokens/content – Apply transformations – Validations
  28. 28. Plugin types - ValueProvider  ValueProvider: creates a custom property-expansion ValueProvider  @PluginValueProvider annotation – valueName property – the text that triggers the provider  Annotated class must implement “DynamicPropertyResolver.ValueProvider” interface  For inserting dynamic content into messages and property values, for example tokens, external data, etc.
  29. 29. Plugin types – Listeners  Listener: creates an event listener  @ListenerConfiguration annotation – no properties  Annotated class must implement one of the supported SoapUI listener interfaces  Powerful way to react to SoapUI events, for example you could; – If a TestCase fails – automatically report a bug in issuetracker – When a load-test finishes, automatically write results to database – When a project is added – prompt user if they want to do X – Etc…
  30. 30. Execution related Listener interfaces  Functional Tests: – TestRunListener – TestSuiteRunListener – ProjectRunListener  MockRunListener  LoadTestRunListener  SecurityTestRunListener  SubmitListener
  31. 31. Object-modification related listeners  WorkspaceListener – Notifies when projects get added/removed/opened/closed – Notifies when workspaces are switched  ProjectListener – Notifies when Interfaces, TestSuites, MockServices and Environments get added/removed – Notifies when projects are loaded / saved  InterfaceListener – Notifies when Operations and Requests are added/removed  TestSuiteListener – Notifies when TestCases, TestSteps, LoadTests and SecurityTests are added/removed  Most objects also support standard Java propertyListeners for observing changes
  32. 32. SOAPUI INTERNALS How to know your way around
  33. 33. The SoapUI Object Model  Defined in com.eviware.soapui.model.* packages  Workspace – Project • Interface->Operation->(Action)->Request • TestSuites->TestCase->  TestStep/LoadTest/SecurityTest • MockServices->MockOperation->MockResponse  Common methods for navigating; – getXXXCount(), getXXXAt( index ), getXXXList() – getXXXs – gets a Map<String, XXX.class> – getYYY for getting parents
  34. 34. The SoapUI Pro API Javadoc available at http://www.soapui.org/apidocs/ Code completion is your friend  Useful classes include  SoapUI (soon to be deprecated)  SimpleDialog  UISupport
  35. 35. UISupport Very useful class for interacting with the SoapUI Pro GUI  UISupport.showInfoMessage(String)  UISupport.confirm(String, String)  UISupport.selectAndShow(ModelItem) … and much more ..
  36. 36. How to get help!  Have a look at existing open-source plugins – RAML plugin: https://github.com/olensmar/soapui-raml-plugin – Swagger plugin: https://github.com/olensmar/soapui-swagger-plugin – API-Blueprint plugin: https://github.com/olensmar/soapui-blueprint- plugin  SoapUI open-source codebase is the foundation of SoapUI Pro  Don’t be afraid of asking on the forum, on twitter, etc
  37. 37. Demo Questions? #SoapUIPlugins

×