What we're about

Technical Excellence is the foundation of sustainable software engineering. Without technical excellence, there's no quality; the development is slow and cannot be sustainable. Without technical excellence, there's no agility.

Do you want to share knowledge about software quality, to build better products?

This group is for engineering leaders and software developers who are motivated by building high-quality solutions and continuously improving. Technical Excellence is both a mindset and a set of practices to help us build quality software faster and deliver value sooner.

Our focus will be on the following topics:

  • Extreme Programming
  • Software Craftsmanship
  • Continuous Integration
  • Continuous Delivery
  • Trunk Based Development
  • Test Driven Development
  • Hexagonal Architecture
  • Clean Architecture
  • Domain Driven Design
  • Use Case Driven Design
  • System Design
  • Clean Code
  • Refactoring
  • Technical Leadership
  • Learning Culture

Our sessions will be in English, held remotely, and open to participants across the globe.

Our goal is to share knowledge, discuss diverse perspectives and synthesize our collective knowledge.

You can follow us on:

Founder: Tech Excellence was founded by Valentina Cupać, Technical Coach @ Optivem.

Community Guidelines: We want to build a safe community. Please ensure you have an appropriate profile photo image. When posting comments, please ensure your communication is professional. In the case of violation of these guidelines, your membership will be revoked.

Upcoming events (2)

Getting out of Legacy with 3P (Johan Martinsson)

Link visible for attendees

When you write tests or refactor at the end of a story, or worse in a separate story, who gets the benefits? And when?

Unfortunately it's the next person who touches the code ... sometime in the future ... if we're lucky. Given that the tests remain relevant. And given that the refactoring actually helps with the new functionality, that we don't know yet ... 🤔

That means our efforts in refactoring and tests are primarily for other people, sometime in the future and of uncertain value to them. Is it surprising if we don't do much of it and let the code rot?

An alternative, that maximizes the ROI of the tests and the refactoring, would be the Protect-Prepare-Produce method 🧐.

Protect
Write quick and dirty(!) tests to protect refactoring in the next step. Beware this can hurt some sensitive viewers.

Prepare
Refactor in depth to make the new functionality easier. Also make the code testable and improve the tests written in the previous step.

Produce
Code the new functionality in TDD. Should be a piece of cake given the Prepare phase.

Being the primary beneficiaries of the testing and refactoring we do ourselves means more happiness. With a much better ROI on testing and refactoring, we're likely to have a lot more of it.

Let's make this clear with a few examples. Not the least what I mean by QUICK and DIRTY tests.

ABOUT JOHAN

Johan Martinsson is a freelance dev coach, passionate about code and software design.

A serial kata-creator and co-creator of conferences SnowCamp and AlpesCraft, facilitator of regular meetups since 2009, he often finds (good) excuses for showing code at conferences.

Component-driven development with React & DOM testing (Paul Hammond)

Link visible for attendees

In this talk, we will explore the topic of Component-Driven Development with React & DOM Testing, delving into the practical aspects of Test-Driven Development (TDD) for web development with a focus on React and its ecosystem. The audience will gain an understanding of how to create accessible and reusable components, use Storybook for UI development, and address common concerns about DOM testing.

Rough Agenda Outline:

1. Introduction

  • The role of TDD in web development
  • The React ecosystem and its relationship with TDD

2. Benefits of Component-Driven Development

  • Thinking in terms of components
  • Reusability and composition
  • Accessibility wins
  • Using Storybook for UI development

3. Addressing DOM Testing Concerns

  • Dispelling misconceptions about DOM testing
  • Demonstrating the speed and efficiency of virtual DOM tests
  • Handling design changes and refactoring with confidence

4. Building a Feature End-to-End

  • Identifying new components
  • Developing HTML structure and CSS in Storybook
  • Test-driving the React component
  • Integrating into a fictional website with API calls
  • Mocking API calls using Mock Service Worker (MSW)
  • Demonstrating how we can refactor the feature with high confidence

5. Q&A Session

  • Responding to audience questions

ABOUT PAUL

I’ve been working in the industry for about 15 years. I’ve been doing TDD for about 10 years and have been doing TDD on the front end with React since the first version of React was released (around 2014).

I’ve worked at places like Electronic Arts, BBC Sport, Sky and Equal Experts, and have successfully delivered many large projects at scale using TDD in all of these places.

I believe the purpose of good tests is to give us the confidence to make changes over time, and I’d like to show some of the tools and techniques I use to make this happen in this talk.

Past events (24)

Help! We have a QA problem! (Niels Malotaux)

This event has passed