Posts Tagged ‘java’

Cloud Foundry Certified Developer Program Your Exclusive Chance to be in the BETA

Your Exclusive Chance to be in the BETA

It is with unbridled excitement that we continue to prepare for Cloud Foundry Summit in Santa Clara. Here at the DellEMC Dojo and the larger Technology, Research, Innovation Group of DellEMC, gears are constantly turning and research and development is moving at a pace unprecedented. We are so excited to share some of these findings and demos with all those related to and involved with the Foundation.

While all is under works, we want to ensure that we and all those we care about are taking up every opportunity possible to continue to develop ourselves further as thought provoking leaders in the industry and in the world. Part of this is keeping ourselves relevant in what exists and then further acting as promoters for the solutions we have found work best. Which brings me to the reason for writing this blog post.

If you have not yet heard, The Cloud Foundry Foundation has been working toward the launch of a “Cloud Foundry Certified Developer” program. The date is getting closer and closer to its unveiling, and it is now more pressing to share the intent of the program so that all wanting and willing to get involved take the opportunity to do so.

The intent of the program is to use a performance-based testing methodology to certify that individual developers/engineers have the skills necessary to be productive developing applications on top of the Cloud Foundry platform. This will allow for a better streamlined data-driven approach to the way we contribute to the Open Source community and our more intimate communities as well. To be active leaders in this realm should be something we are striving for daily. To be PRODUCTIVE active leaders who can then go forth and teach with a congruent and strong set of skills is the mark we should be making, reaching and expanding. So here is how:

The Foundation is currently accepting applications from individuals that may want to participate in the BETA or early access program. If you (or anyone in your organization) are interested in being among the first certified developers, please use the Google Form found here to register interest:

A NOTE: All applications for participation should be filed by March 10th.

The space is limited so the BETA program will be short-listed to 30 candidates, and will communicate with everyone completing the form as to their acceptance into the program. Those that are not accepted will be offered an opportunity to enter the early access phase of the rollout. Developers that pass the exam either during the BETA or early access will get a fancy CF Certified Dev sweatshirt, also… so no harm, no foul!

The BETA period will begin on March 20th and close on March 31st. Candidates will be asked to use the system to schedule a four hour exam window during the two weeks of BETA testing.

Passing the exam requires practical hands-on skills in the following: (1) CF Basics, (2) Troubleshooting Applications and CF Configurations, (3) Application Security, (4) Working with Services, (5) Application Management, (6) Cloud Native Architectural Principles, (7) Container Management within CF, (8) Candidates should be comfortable modifying simple Java, Node.js or Ruby Applications.

You think you have what it takes? We think you do too. So apply today!

Introducing Ginkgo4J Ginkgo for Java

Ginkgo for Java

Paul Warren

Paul Warren

Paul Warren

Latest posts by Paul Warren (see all)

Having been an engineer using Java since pretty much version 1, and having practiced TDD for the best part of 10 years one thing that always bothered me was the lack of structure and context that Java testing frameworks like JUnit provided.  On larger code bases, with many developers, this problem can become quite accute. When pair programming I have sometimes even had to say to my pair

“Give me 15 minutes to figure out what this test is actually doing!”

The fact of the matter is that the method name is simply not enough to convey the required given, when, then semantics present in all tests.

I recently made a switch in job roles. Whilst I stayed with EMC, I left the Documentum division (ECD) with whom I had been for 17 years and moved to the EMC Dojo & Cloud Platform Team, whose remit is to help EMC make a transition to the 3rd platform.  As a result I am now based in the Pivotal office in San Francisco, I pair program and I am now working in Golang.

Golang has a testing framework called Ginkgo that was actually created by one of Pivotal’s VPs Onsi Fakhouri.  It mirrors frameworks from other languages like RSpec in Ruby.  All of these framework provide a very simply DSL that the developer can use in his test to build up a described context with closures. Having practiced this for the last six months I personally find this way of writing tests very useful.  Perhaps the most useful when I pick up an existing test and try to modify it.

Java version 8 has included it’s version of closures, called Lambda’s.  Whilst there aren’t quite as flexible as some of their equivalents in other languages; all variable access must be to ‘finals’ for example, they are sufficient to build an equivalent testing DSL.  So that’s what I decided to do with Ginkgo4J, pronounced Ginkgo for Java.

So let’s take a quick look at how it works.

In your Java 8 project, add a new test class called as follows:

  package com.github.paulcwarren.ginkgo4j.examples;

  import static com.github.paulcwarren.ginkgo4j.Ginkgo4jDSL.*;
  import org.junit.runner.RunWith;
  import com.github.paulcwarren.ginkgo4j.Ginkgo4jRunner;

  public class BookTests {
      Describe("A describe", () -> {

Let’s break this down:

  • The imports Ginkgo4jDSL.* and Ginkgo4jRunner add Ginkgo4J’s DSL and JUnit runner. The Junit runner allows these style of tests to be run in all IDEs supporting Junit (basically all of them) and also in build tools such as Ant, Maven and Gradle.
  • We add a top-level Describe container using Ginkgo4J’s Describe(String title, ExecutableBlock block) method. The top-level braces {}trick allows us to evaluate the Describe at the top level without having to wrap it.
  • The 2nd argument to the Describe () -> {} is a lambda expression defining an anonymous class that implements the ExecutableBlock interface.  

The 2nd argument lamdba expression to the Describe will contain our specs.  So let’s add some now to test our Book class.

  private Book longBook;
  private Book shortBook;
      Describe("Book", () -> {
        BeforeEach(() -> {
          longBook = new Book("Les Miserables", "Victor Hugo", 1488);
          shortBook = new Book("Fox In Socks", "Dr. Seuss", 24);

      Context("Categorizing book length", () -> {
        Context("With more than 300 pages", () -> {
          It("should be a novel", () -> {
            assertThat(longBook.categoryByLength(), is("NOVEL"));

        Context("With fewer than 300 pages", () -> {
          It("should be a short story", () -> {
            assertThat(shortBook.categoryByLength(), is("NOVELLA"));

Let’s break this down:

  • Ginkgo4J makes extensive use of lambdas to allow you to build descriptive test suites.
    You should make use of Describe and Context containers to expressively organize the behavior of your code.
  • You can use BeforeEach to set up state for your specs.  You use It to specify a single spec.
    In order to share state between a BeforeEach and an It you must use member variables.
  • In this case we use Hamcrest’s assertThat syntax to make expectations on the categoryByLength() method.

Assuming a Book model with this behavior, running this JUnit test in Eclipse (or Intellij) will yield:
Screen Shot 2016-06-02 at 8.31.35 AM



Focussed Specs

It is often convenient, when developing, to be able to run a subset of specs.  Ginkgo4J allows you to focus individual specs or whole containers of specs programmatically by adding an F in front of your Describe, Context, and It:

FDescribe("some behavior", () -> { ... })
FContext("some scenario", () -> { ... })
FIt("some assertion", () -> { ... })

doing so instructs Ginkgo4J to only run those specs.  To run all specs, you’ll need to go back and remove all the Fs.

Parallel Specs

Ginkgo4J has support for running specs in parallel. It does this by spawning separate threads and dividing the specs evenly among these threads. Parallelism is on by default and will use 4 threads. If you wish to modify this you can add the additional annotation to your test class:-


which will instruct Ginkgo4J to run a single thread.

Spring Support

Ginkgo4J also offers native support for Spring. To test a Spring application context simply replace the @RunWith(Ginkgo4jRunner.class) with @RunWith(Ginkgo4jSpringRunner.class) and initialize you test class’ Spring application context in exactly the same way you normally would when using Spring’s SpringJUnit4ClassRunner.

  @SpringApplicationConfiguration(classes = Ginkgo4jSpringApplication.class)
  public class Ginkgo4jSpringApplicationTests {

  HelloService helloService;
      Describe("Spring intergation", () -> {
        It("should be able to use spring beans", () -> {
          assertThat(helloService, is(not(nullValue())));

        Context("hello service", () -> {
          It("should say hello", () -> {
            assertThat(helloService.sayHello("World"), is("Hello World!"));

  public void noop() {

The nooptest @Test method is required as Spring’s JUnit runner requires at least one test class.

Trying it out for yourself

Please feel free to try it out on your Java projects. For a maven project add:


or for a Gradle project add:

compile ‘com.github.paulcwarren:ginkgo4j:1.0.0’

for others see here.

Follow Us on Twitter

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.