Tag Archives: spring-days

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!

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!

cloud native streaming and event driven microservices – live blogging from spring days

Posted on by
Reply

Cloud-Native Streaming and Event-Driven Microservices
Speaker: Marius Bogoevici
See list of all blog posts from conference

Streaming

  • Streaming is processing large quantitiesof data as fast as possible -near real time.
  • Collection of eents – in order
  • Good for real time ELT, predictive maintenance, fraud detection, QoS, etc
  • high throughput/low latency

Microservices

  • Cohesive, organizational allignment (Conway’s law)/li>
  • Development agility – optimized for replacement, enable continuous delivery
  • Failure isolation
  • Granlar resource tuning – can scale specificparts of pipeline

Event driven microservices

  • Communicate thrugh message broker vs http
  • Decoupled
  • Publish/subscribe makes it easy to add new elements

Think about opertional complexity – need to be able to provision/montitor. Want this part to be boring. It’s not the business value. Hence cloud-native; the platform should take care of these concerns.
Support Spring WebFlow- Cloud Foundry, Apache Mesos, Kubernetes, Apache YARN

Spring XD – first incarnation. In 2015, it turned into Spring Cloud Stream/Task/Data Flow.

Spring Cloud stream

  • event-driven microservices framework
  • Built on Spring Boot and Spring Integration
  • Binder abstraction – core of framework – connects channels to messaging middleware of your choice
  • Apache Kafka and Rabbit MQ are prod ready support
  • Based on pipes and filters. The logic is in the fiters

    • Spring Cloud Data Flow

    • Orchestration of services
    • Provides Stream DSL
    • Describe deployment
    • Deploys using SPI (service provider interface)
    • Deployment descritpor to specify what want to happen

    Interesting. And we got to read more Flux code. Appreciating Victor’s talk from yesterday even more! I would have liked if “opinionated primitives” was described more. While I understand what the concept means, I’m not that clear on how it relates to the framework. I also had to Google the term SPI. This might have been a presentation for which I lacked pre-req knowledge. The session felt longer than the others. Checking the log for this blog post, it was a little longer; but not a ton so. I think just too much sitting for me!