Throw a line of code into many codebases and it's sure to hit one or more testing frameworks. There's no shortage of frameworks for testing, each with their particular spin and set of conventions, but that glut is not always matched by a clear vision of how to structure and use tests — a framework is a vehicle, but you still need to know how to drive.
This talk takes a deep dive into testing, with a strong focus on unit testing, looking at examples and counterexamples in Java and JUnit 5, as well as other languages and frameworks, from naming to nesting, exploring the benefits of data-driven testing, the trade-offs between example-based and property-based testing, how to get the most out of the common given–when–then refrain and knowing how far to follow it.Throw a
It has been said that immutability changes everything. But what does that mean in practice? What does it mean for existing code that looks more like the mutant apocalypse than an elegant application of mathematical thinking?
Immutability can be an ideal that is hard to reach. Refactoring, on the other hand, is all about the art of the possible. In this talk we'll be clarifying motivation and exploring some approaches to help reducing state mutability in code.
It is very easy to get stuck in one way of doing things. This is as true of programming as it is of life. Although a programming paradigm represents a set of stylistic choices, it is much more than this: a programming paradigm also represents a way of thinking. Having only way to think about problems is too limiting. A programming paradigm represents a set of patterns of problem framing and solving and contains the ingredients of software architecture. As Émile Auguste Chartier noted, there is nothing more dangerous than an idea when you have only one idea.
Perhaps even more problematic than being stuck with a narrow view of paradigms, is being stuck with a dysfunctional view of each paradigm. For instance, many developers working in languages and frameworks that support object orientation lack a strong idea of the principles of interaction, data abstraction and granularity that support an effective view of OO, and instead surround themselves with manager objects, singletons and DTOs.
This session explores the strengths and weaknesses of different programming styles, patterns and paradigms in Java and other JVM languages.
The SOLID principles are often presented as being core to good code design practice. Each of S, O, L, I and D do not, however, necessarily mean what programmers expect they mean or are taught. By understanding this range of beliefs we can learn more about practices for objects, components and interfaces than just S, O, L, I and D.
This talk reviews the SOLID principles and reveals contradictions and different interpretations. It is through paradoxes and surprises we often gain insights. We will leave SOLID somewhat more fluid, but having learnt from them more than expected.
Code is the stuff of software. It is the definition of the software. It is the enabler of functionality, the realizer of business value, the expression of understanding. It is also an expression of misunderstanding, a resister of change, a source of sunk costs. But the word code has meanings beyond source and binary. In a broader sense, code and codes are also the stuff of software development. There are cultures of programming, principles of practice, manifestos of desire. Code refers to a set of conventions by which a group of people will govern themselves.