JavaOne – Java Test Automation for REST, Web and Mobile

“Java Test Automation for REST, Web and Mobile”

Speaker: Edson Yanaga & Elias Nogueira

Code had https://github.com/eliasnogueira/javaone-testing-automation

For more blog posts from JavaOne, see the table of contents


Toolbox for testing

  1. Test real REST Service – intermediate validation between back and front end
  2. Test mock REST service – so can guarantee stability during test cycles
  3. Test mobile UI – functional and acceptance tests
  4. Test Web UI – functional and acceptance tests

Test REST web service

  • Just as important as UI
  • Swagger – REST API documentation
  • Use curl or PostMan to manually validate before trying to automate. Postman provides a UI for running REST calls.

Mock REST web service

  • Spark – microframework for Java 8
  • Good discussion of why record/replay shouldn’t be the only tool for testers
  • Spark is a call to get (or the appropriate verb) method taking params for the URL and then a lambda for request/response logic
  • Rest Assured for testing – can integrate with Spark. Fluent API style

Test Web UI

  • Selenium for in browser testing.
  • Nobody in the room is using Selenium IDE. [good that everyone using it is on RC!]
  • Selenium uses a browser specific executable file
  • Workflow – Navigation, Integration (find a web element), Manipulation (click/update text), Synchronization (wait for dynamic elements/async request)
  • Chrome gives a warning that automated software opened the window [that’s awesome! you know it isn’t malicious if you did it and you know which isn’t your interactive session]

Test mobile UI

  • Appium uses same API/DSL as Selenium.
  • Can run Appium test on real device or emulator
  • Workflow – Desired Capabilities (ex: size), Session (start session), Interrogation/Manipulation, Synchronization

Best practices

  • Test against server, not just your machine
  • Use software to change the internet speed
  • Use page objects so test scripts are modular
  • Avoid XPATH
  • For mobile, have scripts for both fresh and pre-installed apps

My take: Good end to the day. It was nice to see a bunch of tools in a short time both on slides and with demos/live coding of each. The presenters were one tester and one developer creating a bunch of jokes back and forth.

 

JavaOne – Building and Testing Java 9 Applications with Gradle

“Building and Testing Java 9 Applications with Gradle”

Speaker: Cédric Champeau
Deck on GitHub

For more blog posts from JavaOne, see the table of contents


General

  • First version of Java that is not backward compatible
  • Did review of Java 9 modules
  • Gradle can run on Java 8 or 9.
  • No built in support for module path
  • Some plugins don’t work – ex: FindBugs. Will be hard to figure out if plugin or Gradle’s fault. Some mocking frameworks will require upgrade as well.
  • Gradle 3.4 introduce a Java library plugin so can separate API and implementations dependencies. Just like modules!

Migrating to Java 9

  • Sample app with 6 modules
  • Uses reflection and service loader code so non trivial
  • implementation (requires) vs api (transitive ok) – paves way for Java 9
  • Replace META-INF/services with “provides” in module-info

Testing

  • want to compile main and tests separately. is that one or two modules? if two modules, prevent from seeing each other.
  • hack the java compiler task to give it the classpath as module path
  • use a patch module so main and test code are one module and the tests can access the package private classes. Also gives JUnit the right to read the classes.
  • so still compile separately but create one module

Automatic modules

  • “How many of you have a jar named util.jar?”
  • Reserve automatic module name now by setting Automatic-Module-Name in the manifest
  • They when upgrade to Java 9, use that name

Multi-Release Jars

  • Said multi-release jars are a bad idea because odds are low the dependencies are the same
  • Old way was to use reflection to determine which version available
  • /src/main/java – shared sources
  • /src/main/java9 – java 9 specific sources
  • Tell gradle which versions of Java to compile each with and differences in dependencies
  • ex: java9Implementation for dependencies – points it to shared sources

Future

  • Working on experimental jigsaw plugin which takes care of various tweaks demoed today. org.gradle.java.experimental-jigsaw

My take: This was interesting. I was a little distracted because I realized I needed to figure out a few presentation things for a larger room. So I was doing a little setup on my computer for tomorrow. It was hard to multi-task though. Cédric’s presentation was good and kept pulling me in :). Also the story teller app was cute. So I wasn’t satisfied in my level of paying attention or my level of getting ready for tomorrow. Oh well. I proved the downsides of “multi-tasking”.

JavaOne: JUnit 5 Features, Architecture and Extensibility

“JUnit 5 Features, Architecture and Extensibility”

Speaker: Steve Moyer, Stephen Seltzer & Niraja Ramesh
Deck on GitHub

For more blog posts from JavaOne, see the table of contents


This is “part 2” because last year they gave a session. It’s an expanded version of that talk now that JUnit 5 is done.

Rationale

  • Decouple test execution/reporting from test definition/provisioning
  • JUnit 8 features. ex: message nw last param and can be lambda
  • migration-support – JUnit 4 rules
  • junit-platform-console – to execute from command line; have to build full classpath

Principles

  • Prefer extension points over features
  • An extension point shoul be good at one thing
  • Should be hard to write tests that behave differently based on how run
  • Test should be easy to understand
  • Minimize dependencies; epecially third party

Features

  • Meta Annotations – compose annotations out of other annotations
  • Tags/filters
  • Dependency injection through params on constructors/methods
  • Default interface methods

Code examples (also on GitHub

  • Assertions – assertEquals(expected, actual, message)
  • Skip tests @Disabled
  • Lambdas – assertTrue(a, () -> message)
  • Grouped assertions – assertAll(message, () -> assertEquals(expected, actual, essage))
  • Exceptions – assertThrows
  • Assumptions assumeTrue, assumeFalse, assumingThat – he last one sets a scope (lambda) for the assumption and continues after that block regardless
  • Meta-annotations Create annotation with other annotation. Similarly can tag tests with annotations. Eclipse lets you specify filters in run config
  • Repeated tests – pass how many times to run along with what to display – can pass current repetition an tota reptitions to display name. Not for performance testing (other tools for that) but good for idempotence testing
  • Parameterized tests – can feed in CSVFileSource, CSVSource (CSV as strings), MethodSource. See docs for implicit conversions [didn’t mention value source :(]
  • Test templates – designed to be invoked multiple times and run like indepenendent test method. Parameterized tests are an implmentation of test templates
  • Lots of extension points and callbacks. Can programmatially decide whether to run tests.
  • ParameterResolvers – TestInfo (has display name, test class and test method), TestReporter (allows publising to output report) – can have JUnit pass as param to test
  • Callback order – BeforeAll, BeforeEach, BeforeTestExecution, Test, AfterTestExcution, AfterEach, AfterAll. Does parent class before child on Before*** and after child on After***
  • Dynamic tests – use @TestFactory – have display name and Executable interface
  • Grouped tests – Can use traditional for loop, assertAll or factory tests. Different output. Traditional for loop only ells you about first failure. With assertAll, get all failures but one faling test. With factory tests, you have a failing test for each faiure.

Future