The hyped, happening and happened programming languages and testing frameworks @ bol.com

On 6-09-2021
Category: Development

The hyped, happening and happened programming languages and testing frameworks @ bol.com

We asked 25 developers, five tech leads and someone “who does unspeakable things with technology” – more commonly known as our principle tech lead which technologies (tools, libraries, language or frameworks) they believe are hyped, happening or happened:

  • hyped – which new technologies are you eager to learn more about this year?
  • happening – are there any exciting technologies you used last year that we should learn this year?
  • happened – did you walk away from any technologies last year?

This is what we got back:

Venn2

 

This blog post, which is part of a series of six blog posts in total, we have a closer look at programming languages and testing frameworks:
Programming Testing

Here you can find a complete overview of all blogs in this series.

Programming languages

We asked our questions to developers and coding is what they do. So, you can expect to find at least some different programming languages – and different opinions about them – in the answers received.

Java

Let’s start with the one language that has been in the top three of popular programming languages for 20 years already: Java (https://www.tiobe.com/tiobe-index/java/).

Just in case you wonder why we are walking away from Java 8: it is because it is 2021. There are better alternatives out there such as Java 11 or the soon to be released Java 17 version, both of which are long term support versions. But it is not only Java that is a good alternative to Java. As can be seen from the TIOBE index, Java’s popularity is eaten up by other programming languages on the rise. Some of which are gaining popularity in bol.com also.

Rust

Despite its name sounding old and worn out, Rust is a relatively new language. The first stable release appeared in early 2015. Rust – as the authors themselves say – is a language empowering everyone to build reliable and efficient software. It strongly emphasises safety, control of memory layout, and concurrency.

Rust looks mostly like C++. Now, we have to admit that that does not directly enthuse us, because as Steve Taylor once said: “C++: an octopus made by nailing extra legs onto a dog.” But do not get thrown off by that, because as one of the respondents goes:

“Rust is a modern programming language that has reached a level of maturity that positions it to replace what might currently be reserved for C++ use cases.”

What really caught our attention, though, is that Rust has no garbage collector that cleans up your unused data after you. It still guarantees memory safety, however. So, no risk of memory leaks and no unexpected pauses caused by the garbage collector? Interesting.

Kotlin

Developers tend to have a strong opinion on programming languages. The answers we received about Kotlin confirm this:

“Kotlin is more expressive and joyful to work with [compared to Java].”

“[Kotlin] is a perfectly inflated hype spread in the form of the-next-big-thing without a single benefit but more puzzling bugs in addition to the ones that you already get from JVM while programming in Java.”

Kotlin claims to be a concise, safe and interoperable programming language that runs on the JVM.

It is concise because it offers powerful constructs that allow you to achieve a lot in only a few lines of code. Think of creating a complete immutable object with hash, copy and equals method in one single line. Or, implementing the delegator pattern, also in one single line.

The unique way of preventing null pointer exceptions is probably the most obvious example that shows Kotlin’s safety. But Kotlin offers more. What do you for example think of the automatic casts that are inserted after you checked the type of an object in an if-statement? Because Kotlin does it for you, you won’t risk the mistake of casting it to the wrong type. And did the omission of type declarations make you question Kotlin’s safety? No worries, Kotlin is a statically typed language, meaning that all your type-related mistakes are already caught before you run your application. That’s right, you are only allowed to omit types that can be inferred at compile time.

Another strong point of Kotlin is that it seamlessly integrates with Java. Indeed, it is very easy to call Kotlin code from Java and the other way around. IntelliJ can even convert existing Java code to Kotlin! So, no need to wait for the next greenfield project to start with Kotlin.

Go

Go has already been popular within bol.com for some years and it still is. The Go language was born at Google from a shared dislike of the C++ programming language and with the goal of making programmers more productive. In particular it claims to be expressive, concise, clean, and efficient. Where have we heard that before?

We would not be surprised to see Go’s popularity at bol.com increase over the next few years, because it seems to chase the same goals as the other languages mentioned earlier and it integrates seamlessly with the Google Cloud. Indeed, as one developer says: “Go and the cloud are a match made in heaven.” Or as Google themselves says: “the Google cloud is built on Go.” [https://cloud.google.com/go/home]

Scala

Just like Kotlin, Scala offers a wealth of constructs that make us achieve more in fewer lines of code than in Java. Even more than Kotlin, Scala heavily focuses on combining functional programming with object-orientation. Its higher order functions, tail recursion and its expressive pattern matching – to just name a few – make it a very powerful language.

The vast amount of functional programming concepts makes Scala have a steep learning curve for people with a less strong background in functional programming. And that might be one of the reasons why – a language that was popular within bol.com for a long time – is being walked away from, seemingly in favour of other languages like Kotlin, that have a significantly less steep curve to learn.

Python

Python is a concise, easy to read programming language that allows you to write programs quickly. Basically, it can be used for anything. You can use it for building web applications, doing data science projects (there are a lot of useful Python based data science libraries out there) or writing performance tests (for example in Locust). That is probably why it is already popular for quite some time (https://www.tiobe.com/tiobe-index/python/) and bol.com is no exception to that.

TypeScript

Put crudely, TypeScript is an improved version of JavaScript. It is common knowledge that fixing a bug costs more the later you find it. TypeScript saves you from these costs by catching errors early on. It does so by adding static types to JavaScript.

Already implemented all your code in JavaScript? That shouldn’t be a problem, because TypeScript is a strict superset of JavaScript. That is to say, each valid JavaScript program is also a valid TypeScript program.

The popularity of TypeScript goes hand in hand with the increasing popularity of Angular. In fact, TypeScript is a primary language for Angular application development.

Testing frameworks

If you ask 25 software developers about their favourite technologies, you wouldn’t expect to find any testing frameworks in the responses, would you? After all, we only hire top developers who write flawless code. This reasoning is clearly flawed. If you want to write flawless code, you have to prove it is flawless by writing flawless tests. Luckily, there are some nice testing frameworks to help us with that.

JUnit

JUnit is the most well known open source unit testing framework within the Java community. It is part of the collective unit test frameworks called xUnit. JUnit works very well with developers who use test-driven-development (TDD). JUnit provides a lot of features and annotations which add a lot of power and convenience to unit testing, such as:

  • Nested testing – opens up whole new opportunities to group tests which belong together 
  • @DisplayName annotation – allows you to add a descriptive name for test cases which can be used while generating test reports, you can even add emojis 😉
  • @ExtendWith annotation – allows integration of the test context with other frameworks such as Spring
  • Parameterized tests – allows running a single unit test with multiple different values

JUnit 5 is the latest version which builds up and adds even more features than JUnit 4 such as:

  • Making use of Java 8 features such as lambda functions, making tests easier to write
  • Unlike JUnit 4 where the entire library is in a single jar, JUnit 5 has granularity and its functionality is spread across different jars
  • JUnit 5 allows multiple test runners to run in parallel

JMockit and Mockito

Sometimes, an object under test has dependencies on several other objects. This makes it hard to unit test a single class in isolation. In short, mocking is creating objects that simulate the behaviour of real objects. The process of mocking involves initializing a mock of the external objects and returning a suitable value when a function in the mocked object is called. It is also worth mentioning that not all tests should have mocking in them, sometimes we want to test the entire flow of the application with an integration test.

First let’s take a look at the most common uses for mocking objects, to:

  • Test a specific functionality in isolation by mocking away complex external logic
  • Test how many times a specific piece of code is being invoked
  • Verify if a function is being called with the right arguments
  • Partially mock an object which uses the real implementation for some of its methods

There are several java mocking frameworks out there, two of the most commonly used ones are JMockit and Mockito. Both these frameworks support most common mocking features, and are easily configurable. There are some slight differences however:

  • Mockito requires a special annotation for partial mocks. JMockit, however, has it out of the box – any method which has no mocked behaviour will call the real implementation.
  • JMockit forces you to test in a specific structure, i.e. the record-replay-verify model. This is a flow where initially the code under test is prepared, then the test function is invoked, followed by verifying if the assertions are what we expect.
  • JMockit allows mocking of static methods and private fields. This is not possible in Mockito.

Mockk

Got something to mock, but wrote your application in Kotlin? Because of Kotlin’s great interoperability you could still use a Java based mocking framework, of course. But why not use Mockk – a mocking framework for Kotlin?

ArchUnit

A common problem faced by developers is that the code architecture can change, which can have unintended consequences. ArchUnit is a library for checking the architecture of your Java code. It can analyse dependencies between packages and classes, check for cyclic dependencies, make sure there are no system.out calls, etc. Another one of its selling points is that new team members can learn the architectural rules of the code quickly, and make sure that they don’t violate any rules.

Want to read more about hyped, happening and happened tech at bol.com? Read all about The hyped, happening and happened application frameworks and Java runtime @ bol.com or go back to The hyped, happening and happened tech @ bol.com for a complete overview of all the hyped, happening and happened tech at bol.com.