Daily Archives: June 21, 2017

automated testing for digital experiences using junit 5 – live blogging from spring days

Posted on by
Reply

Automated Testing for Digital Experiences Using JUnit 5
Speaker: Justin Baumgartner
See list of all blog posts from conference

General

  • Asked how many use JUnit 4. Almost everyone. [didn’t ask about TestNG, but did cite most used framework in general]
  • JUnit 4 is ten years old
  • “It’s all about the tests” – TDD/CI/CD – create. more importance on tests

Gaps in JUnit 4

  • Tight coupling between the APIs we use to write tests and the ones build tools use. Separating the jars lets progress at different speeds
  • Built on Java 5. Can’t use lambdas [aside from a tiny bit in assertj]
  • Runner restrictions – can only have one
  • Rules aren’t flexible enough

JUnit 5

  • Release in early fall
  • New architecture: JUnit platform (for build tools and IDEs to discover and execute tests), JUnit Jupiter (for writing tests), JUnit Vintage (to run legacy tests)
  • Potential for Cucumber or Spock runner so can run all tests in one place
  • Extension model: Can hook into life cycle callbacks. Used instead of runners/rules. An extension point is an interface. Example BeforeEachCallback. Need to be stateless; get TestExtensionContext as parameter. Can implement multiple callback if want called multiple times and store state in getStore(context).
  • Can pass parameters into test methods using @ExtendWith(xxx.class) so narrow scope. Implement ParameterResolver to create the object you want to mock.
  • Dynamic tests: create tests at runtime. Not expected to use often. @TestFactory and then create tests as lambdas. Each dynamicTest in list is an actual test (vs run in a loop
  • @ParmeterizedTest and @ValueSources – hard code parameters, read from file. [need to look at how to run “legacy” style parameterized test – answer – there’s. a @MethodSource where you can havve any logic]
  • RepeatedTest(x) – to run test a bunch of times
  • @Disabled – can disable class or test. Appear in report but not run. (unlike @Ignore where don’t appear in report at all)
  • @DisplayName so can print clearer name than test name
  • @Tag – replaces @Category – to grou/filter tests
  • assertAll() – new assertion – facilitates grouping of assertions

Said backward compatible. But not all runners/rules are in Jupiter. So would have to use Vintage test engine to use those or port. Jupiter has different packages for annotations/assertions so can mix within class. So if using Jupiter engine, still can use “old” asserts until change imports.

Nice ending presentation. I’m really excited about JUnit 5!

JHipster 4: Angular and Spring Boot – live blogging from spring days

Posted on by
Reply

JHipster 4: Bringing Together Angular and Spring Boot
Speaker: Yakov Fain
See list of all blog posts from conference

Random facts/quotes from pre JHipster demo

  • Can often judge a framework by how much/little need to do to get started.
  • Write in typescript and gets turned into JavaScript.
  • Pulled files from nodejs.org – which is like Maven Central for JavaScript.
  • ng serve – bundles up js files
  • showed npm scripts to build/deploy

JHipster

  • code generator
  • Based on Yeomen – another code generator

TDD for Microservices Architectures – live blogging from spring days

Posted on by
Reply

TDD for Microservices Architectures
Speaker: Reshmi Krishna and Vinay Upadhya
See list of all blog posts from conference

Showed Martin Fowler’s testing pyramid (unit, integration, component, end-to-end, exploratory) to set vocabulary

Focus with microservices is contract based testing.

Consumer driven contracts (CDC) let the callers specify exactly what they are interested in from a generic API. If everyone does this, you know who uses what fields so don’t remove something that a caller is relying on.

Spring Cloud Contract

  • specifies contracts with Groovy (but mainly DSL so like data structure). Can use other formats such as XML
  • Looks like BDD – request/response except HTTP level.
  • Contracts stored with app under src/test/resources. Or can store in separate project
  • The producer autogenerates stubs/tests and shares with consumer

Libraries

  1. Spring Cloud Contract Verifier – checks service isn’t breaking any consumer contracts
  2. Spring Cloud Contract Wiremock – wrapper around wiremock (wiremock is an API mocking tool)
  3. Spring Cloud Contract Stub Runner – pulls stubs from maven and run with wiremock

Flow

  1. Client app needs an API/field. Client writes test specifying what need. The test specifies workOffline = true to use local stub
  2. Client implements code to call the microservice that implements the new feature [This was worded a “client implements the feature” which is not what they meant upon a few questions and confused me. With my wording (about calling the microservice and seeing the code it makes sense that the client is not implmenting the feature]
  3. Client clones producer repo and define locally – if needed. Or can use common repo for contracts.
  4. Autogenerates tests/stubs for producer based on contracts. The stubs are wiremock JSON. The tests use JUnit/AssertJ.
  5. Client runs verifier tests – now they pass

If later version of service, update URL with version number so have new requirements.

The PowerPoint felt a bit rushed, but the demo was a good pace. I would have liked more mapping between the points in the flow. It’s a lot to remember. But it did mostly come together in my mind. Especially after I asked enough questions to uncover the a bullet in the flow wasn’t actually what happens. (So confused me) From the questions, I could tell that others in the audience were wondering about some details as well. Luckily, I had the step in this post for reference!