Integration tests, part 2 (notes on Cucumber and Selenium)

(This is part 2, some learnings a few weeks into the project described here: Integration tests = secucbootCucumber + Selenium + Spring Boot)

Selenium tricks:

Use the fluent wait instead of anything else, like here waiting for the expected messages to appear. Continue reading

Advertisements

Integration tests = Cucumber + Selenium + Spring Boot

Let’s say you had this web application with nice unit tests covering the backend calculations, where people keep calling wrong calculations from the frontend. Microservices or not, it happens, so you’ll need proper integration testing. Let’s say the integration testing is a well documented but tedious two days job of clicking around. Understandably, everybody does their best to avoid it…

My answer was: how about we rewrite the integration test scenarios in the Gherkin almost-human-readable language, so we can use Cucumber to run them automated, simulating with Selenium the user browser actions! The supporting stack will be Java and Spring, actually Spring Boot, because you know all I have is a hammer….

Continue reading

Ractive.js and vert.x integration over the event bus

Recently I ran into Ractive.js which seemed like something doing exactly what I’d expect from a client side (browser that is) framework – fetch its own data and create nice web pages with that without getting me from the beginning too deep into JavaScript programming. Nota bene: I’m not a JS programmer and Angular or Ember just scare the s* out of me, plus I have strong moderate opinions against massive JavaScript framework programming so Ractive seemed like a convenient compromise. But would I be able to use it? In a vert.x project? Maybe I should try just that… Continue reading

Switching web programming paradigms with vert.x

When I first combined the Internet and programming it was the second half of the 90’s and all I knew was Java applets. Oh, there was also CGI but I somehow managed to skip over it. The approach was then quite natural: write small programs which will run in the browser and grab data from other programs – run in either other browsers or on the server. Or on other servers. I’m not saying the idea was easy and I only got that far before I moved on to other professional areas. Later when I came back to the web, things had settled differently: you had a servlet specification, a multitiered application to support them, big servers and everything was clear. Of course there was some bit of fight over technologies, gradual improvements here and there but the model was there already. Continue reading

Looking for a web end-to-end framework

…but web frameworks are today ten a penny, why would I be still looking for something? Could it be I didn’t look around enough? Am I too finicky? Or blind for not seeing it right in front of me? Whatever, fact is I’m still looking for the „perfect“ web framework. It doesn’t have to be REALLY new – but it certainly would be new to me.

I would like it to be, in no particular order: Continue reading

Vert.x instead of servlets, time for something new

Why

How old are dear servlets? 15 years you say? Hm, maybe it would be time to check on alternative technologies, not because servlets would be necessarily bad but just to check whether new times brought also new concepts forward. And you bet they did – look at Node.js, it‘s quite popular nowadays. JavaScript aside, Node.js has a different way of working – a reactor pattern, not at least a very good way to use the multicore facilities of today’s machines. Node.js is actually not alone in this league – the very popular Nginx (yes, the one stealing Apache web server’s crown) works apparently the same way. But if you want to replace your servlets Java web application, you’ll HAVE to try vert.x. Cool, multithreading without writing yourself threads! NOTE: Worth mentioning here: vert.x can do a lot of stuff and a web application is only one of its possible uses. Continue reading

The story of a plugin

In the beginning the man created CVS. And CVS had some precursors as well, and I don’t care about them as I’m not historian. Thing is only some spirit said, let’s create some software guidelines based on them: and there was Software Guidelines. Java EE software guidelines. Some other spirit saw many years later these guidelines, that they were good: and it wondered why doesn’t our actual code follow them. And it said, let the team create for each file an informational header filled with version-related information: and it was so. Continue reading