Dane's Stuff

Test Properties

2023-01-03T00:00:00Z

In a previous post I talked about testable code. Kent Beck expanded on this a bit with (Test Desiderata) [https://kentbeck.github.io/TestDesiderata/] and talks about properties of good tests. I really like how he talks about combinations and how certain properties can interfere with each other so we have to make trade-offs.

Lets talk about some of the trade-offs with unit tests. There is a mnemonic of (FIRST)[https://medium.com/pragmatic-programmers/unit-tests-are-first-fast-isolated-repeatable-self-verifying-and-timely-a83e8070698e] that states what a unit test should be. These map really well to some of Beck's test properties, but not all of them. It's important to remember that different types of tests have strengths and weaknesses and we should lean into them and use the type that fits what we are trying to accomplish.

Unit tests should be fast, repeatable, deterministic, and easily ran as part of the development. They are more useful for complex pieces of code, especially pieces with lots of variation in inputs. They help find edge cases and refactor code so that it is maintainable. They don't give much feedback on the correctness of the application, they are not very predictive, which is what lots of people mistakenly think they do. However, you get more feedback on the design of a particular section of code and whether changes broke other parts of the code.

However, if we want to ensure a end user can use the UI for some critical functionality, then an end to end test would be more appropriate. We would trade some properties, like fast and specific for some other properties, such as predictive and inspiring.

So depending on what you are trying to do, and what kind of feedback you are trying to gain, determines what kind of tests. A application with mostly UI, might have more end to end and integration test, while one that was more complex calculations would be more focused on unit tests. I think this is a point lots of people miss. Not all tests do the same thing, each one has strengths and weaknesses, and knowing what problem you are trying to solve will allow you to choose the correct test.

Testable Code is Good Code

2022-09-02T00:00:00Z

I talked about testable code in another post. I wanted to expand on that and explain a bit more why testable code makes your code better.

Better code is a subjective term, so let me define a bit about what I mean. By better, I mean it's easier to read, easier to change, smaller methods and classes. Although these things don't necessarily make your code better, you can have these things and your code could still be bad, to me at least, they are things I strive for in my code.

How your tests interact with you code is your first feedback in how hard it is to use the code you are writing. If you (write the code you wish you had in your test)[https://spec.fm/podcasts/developer-tea/b122f924], you start actively designing the interface. Most times if your code is easy to test, its changeable, easy to read.

Again I say mostly, you could make a test library that makes it easy to test the code, or have some code that is just wrong. But if you are testing your code through the code interface and you have problems with you tests, or (code smells)[http://xunitpatterns.com/] it is a good indications that something is lacking in your code design. It could be the test are very big because it doesn't have a single responsibility, or its hard to test certain things because of side effects. Hopefully I will go into more detail in later posts. But whatever they are, those are feedback loops your test are giving you about your unit under test. If you listen to your tests as you write or change your code, many times it will greatly improve your code, or at least highlight some design flaws.

Unit Tests Are Misunderstood

2022-08-09T00:00:00Z

I think some of the misunderstanding of unit tests, is that people don't fully grasp the purpose of unit tests. I often hear things like we don't really need unit tests if we have end-to-end and integration tests, or why do we still have bugs if we have all these unit tests. This really misses the power of writing unit tests.

In the book Growing Object-Oriented Software Guided By Tests (if you haven't read it, I highly recommend it). They explain the difference between internal quality and external quality and how the different types of tests relate to each one.

Higher external quality, which is more what the customer sees, being greater as the test is closer to an end to end test. While at the same time having lower internal quality, which is the state of the code.

A Design Activity

Since writing unit tests is more about internal quality, it is more of a design activity, even if you write your test after, but just not as much.

In order to make code testable, (*which I will expand on in another post), it must be structured in a certain way. Good unit tests steer us in a direction to make the code more cohesive and loosely coupled. And that is the essence of TDD and unit testing, it allows us to easily change our code to adapt to changing requirements, new features, or just better designs.

But we have all been in code bases where the internal quality slips aka Technical Debt, so is it really that important. If we are only focused on what the customer wants, and the customer is happy, does it matter that much. In the short term probably not. However, as the internal quality slips, it becomes harder to add features or not introduce bugs. This is why we need different types of feedback systems when we are developing code, each type of test has it place. In the end we must balance delivering today, without sacrificing our ability to deliver tomorrow.