 This talk is about anti-patterns. I might talk about test smells. So what I mean by test smell is that it's some kind of a hint. It might be the shape of something or the name or some kind of a pain or feeling I get from code, in this case test code, that suggests there might be an issue. So it's not an absolute yes, that's a problem. It's more like there's something funky about this. I should look at it and see if there is something behind. Not necessarily, but that might be the case. So I'm a programmer by background, also a trainer, a coach. I work at a consultancy and basically I spend half of my time working with code, half of my time with methodology. So this is clearly based on the other half where I work with code in a bunch of different organizations and sort of lucky to get exposure to all kinds of code bases. Mostly Java and the examples are Java, but I think that these anti-patterns apply to many languages, not just object oriented languages, many others as well. So here's a piece of the abstract. If you read the abstract for the session, just like to point out the really important parts of the abstract, tests need to be maintained. You hear a lot about when you start talking about thorough unit tests or other kinds of automated tests. One of the main concerns that seems to raise is isn't that a lot of code to maintain? Isn't it a burden if we write so many tests? That's actually exactly what we're trying to avoid by being able to identify and fix test smells. The fact that tests are unmaintainable, that is the ultimate test smell. So we're going to look at a few particular names for things that I've given or somebody else has given and some heuristics around how to think about these things. Now we're talking about smells, which means it's not an absolute, this is good and this is bad. Sometimes what's good in one context, you go to the next source file.