How do I set up Google Cloud to do Behavior Driven Development (BDD) for a web app with an AngularJS client and a Java server?

Question

I want to do Behavior Driven Development (BDD) on Google Cloud. I've written out my BDD stories and it looks like a basic web app will satisfy the requirements. I'd like to use AngularJS for writing client code and Java for the server because these are what I'm most familiar with. I'm also somewhat familiar with Maven.

How do I get started in a way that allows me to focus on writing the code?

1] Select a Google Cloud Service (App Engine, Compute Engine, Container Engine)?

2] Find and copy a Hello World example for any technology that also has as many of the other components as I want to use (JBehave for BDD, AngularJS, Java, a Google Cloud service above)? But which component's getting-started guide should I start with so that the other components integrate easily?

3] Find a suitable Maven archetype?

4] Investigate Spring.io? I've heard that Spring.io tries to make it easy for developers to focus on coding. But I don't know much else about it.

I'd like to spend as little time as possible setting up the project so that I can start doing Behavior Driven Development as quickly as possible. What I normally find happens with a project like this is I lock down one of the decisions about which technology to use, follow their getting started guide, but then run into a brick wall when I start integrating the other components.

How do I start this project so I can spend the least amount of time on non-coding aspects as possible?

Answer 1

One approach is to think front to back or back to front. Thinking front to back means starting with the user interface and once that's built, create the middle tiers, and finally the back end.

The problem with starting with the user interface though is that you can't really verify that it works without a backend. But I believe that's a problem Dependency Injection (DI) solves. You build the user interface and wherever it needs to call the next layer down in the stack (e.g. the server APIs), you instead give it a mock server to call. You can implement enough of the mock server to make the BDD stories pass for the user interface. When every BDD story passes for the user interface, you can then build the next layer down in the stack.

It should be possible to get started with developing the user interface by finding a Hello World example for the front-end technology (AngularJS). Look for a Hello World example that incorporates the two necessary pieces for testing: BDD and Dependency Injection. If you can't find one, then just start with the AngularJS Hello World, get it running. Then as a separate task go do a Hello World for BDD and hopefully it will be apparent after learning how to get BDD working to get BDD working with the AngularJS project. Then do the same for Dependency Injection. Hopefully, that gets you to the point of having an AngularJS fully implemented front-end that you can verify works with BDD and Dependency Injection.

Then you can work on the middle tier. You could set it up as a separate project, independent of the AngularJS project so that you don't have to worry about the hassles of combining code from two layers of the stack into one project. Maven should be able to do that but documentation for Maven tends not to be as easy to use.

To develop the middle tier, find a Hello World example for developing a REST-based API server that runs on Google Cloud. You don't need the front or the back end at this point. The front end can be simulated by the BDD stories and the back end can be simulated by DI. Once all of the BDD stories pass for the middle layer, then you can build the back-end.

Developing the back-end is similar to building the middle-layer. Find a Hello World example for developing a database application that runs on Google Cloud. Most likely the relevant technology is the Google Datastore using Objectify as an Objected Oriented wrapper. But let's call this layer the service layer because there should be a layer of abstraction between the REST API and the datastore. The complication here is might not be very straightforward to develop this layer independently of the middle-tier, but try if possible to do that. In other words, create a separate project that's based on a Google Datastore Hello World example. Use BDD to simulate the middle-tier. You might not need DI anymore because you're at the bottom of the stack, just call the datastore directly. But DI might be useful anyway if it's not possible to run the datastore on your local machine where you're developing.

Now that you have BDD stories functioning on all three layers (User Interface front-end, REST API middle-tier, service layer back-end), now start making it work on the production servers. I'm not confident this is the best approach though because it seems like a lot of complications could arise in this final step. Theoretically, if each layer passed the BDD tests, then it should all zip up together nicely. But integrating it all together might not go that smoothly. One strategy for making sure it goes smoothly is to map each layer onto its own dedicated production system. If each piece ran smoothly on a development machine, shouldn't it run smoothly on a production machine?

Well hopefully, but I'm hoping someone else will propose a better approach that allows someone to spend an even higher proportion of time on coding and a lower proportion of time on this DevOps stuff.

Answer 2

Personally, I would not focus on where to execute the system. I my world, development is done on a local computer. CI is done somewhere else and the final artifacts are executed somewhere. This somewhere must be possible to deploy to from your CI build so you can verify that it actually works before deploying.

I would start by building something that works local on my computer, then move forward. I would not spend any time searching for a Maven archetype, I would slowly build my project manually. This may sound as a slow way of doing it, but it will give me knowledge about what is happening. The magic added is magic I have added and therefore no magic.

Where should you start then? I suggest to start by cloning https://github.com/cucumber/cucumber-java-skeleton and extend it with the business functionality you need. If you need more technology, add it when you need it. Not before you need it. My experience is that I usually need less technical stuff than one could imagine from the start. And definitely not the tooling I could think of before I started the project.