Parsing SVG documents into useful layout specifications

In a previous post, I discussed using SVG documents to specify layouts in a Unity app. More recently, I started delving into that subject and laid out a list of things to cover:

1. How to make the SVG easy to interpret visually.
2. How to convert the SVG into a set of rules.
3. How to select the right rules given a query string.
4. Generating an SVG that explains what went wrong when a test fails.

Among the many things I deferred was how to actually parse the SVG into a set of layout constraints.

Both #2 and #3 are pretty simple and they are strongly related, so I'll handle them in this text.

Extruding Code from Tests

As you may or may not know, I've been working on a game. I've also been experimenting with writing all my code in test files and extracting it.

I think I'm getting it down.

Recently, I built a lobby for my game. It's an in-memory lobby for letting people start a game on their device but it's the first step.

I started a little bit before the below video but this is where it really started getting good.

Sometimes I like to leave a note for myself in the form of a failing test. I would never check it in that way...unless I'm the only one working on the code. I mean at all, not just at the moment.

A Continuation of Yesterday's Theme

In continuing to build my Unity gestures library, I am also continuing to experiment with developing all code in the tests and extracting as needed.

Test-Coverage

Measuring test-coverage tells you almost nothing of value. A disciplined approach leads to high test-coverage. The resulting tests add a lot of value to the development environment.

That correlation isn't something on which you can count, though.

It's like measuring the sharpness of knives in a kitchen. A good cook is going to keep their knives sharp all the time. An amateur cook will probably ignore the a report that their knives are too dull.

The same is true of test-driven development. You're either a professional or you aren't. Either way, test-coverage isn't going to change it.

Most of the time, organizations that are tracking test-coverage end up with something worse than no tests: vast tracts of useless tests that increase cost while providing no real protection.

Does It Matter if You Mock?

Part of me thinks this is a continuation of this post.

I love mocking and experience none of the problems purported by people who seem to hate it. I also recently tried an experiment of writing tests with minimal (so far, no) mocking.

Guess what. I'm experiencing none of the problems purported by people (such as myself) who prefer to writing code with mocking.

What gives?

I've known that whether or not you use a mocking tool, like Moq, doesn't matter. Hand-rolling a mock or writing a test-double with widely-understood behavior works just as well as using a dynamic mocking tool.

Now, I'm beginning to think that whether or not you mock at all isn't really that impactful at all. I think that, when we measure an impact, what we are really measuring is a correlation with something else; something that does matter.

I think what we are measuring is the degree to which a test specifies a single behavior and is insulated from implementation details. I don't know why, but I'm guessing we blame our tools for the success we've experienced.

More on this as I continue to experiment.

Cutting the Issue to Its Core

Be Careful with the Word "Just"

I hear these kinds of claims a lot...

"It's just UI logic."

"That's just database-connectivity code."

This is generally as a preamble to an argument that the code in question can't or should not be tested.

The word "just" sometimes is used in its true meaning. That is, sometimes you have a method that really does just do some small thing that's unduly expensive to test.

Most of the time, the word "just" hides something else. Often the phrase "that's just X" really means "I can't imagine how to separate everything in that method that's not X from X."

One might be tempted to call this "just"-ification.

It's okay to have some of your code not be covered in tests. You just shouldn't feel the urge to explain yourself when you do. It should be self-evident that a method or class is just glue code to some peripheral component.

If you find yourself explaining to someone else - or to yourself - that a block of code is just something, make sure you take a beat and verify. Is it really "just", or is it "just"-ification?

Procedural and Environmental Approaches

I have a friend, Eran Pe'er, of DevCraft, who likens refactoring to the procedures and preferences of Brazillian Jiu-Jitsu. I don't know much about Brazillian Jie-Jitsu but I know about this way of thinking.

Every situation has a list of situations that are better than it. The transitions between certain situations are well-defined and can be learned, practiced, and shared. It's a good analogy for a style of refactoring. In this style, it is the procedures of transformation which give us our safety. A nice property of this is that it is environment-independent; you can do it with or without a meaningful battery of tests.

A procedure lets you make your situation better in a relatively-predictable way

I have a different approach; this was especially the case before I met Eran. For me, getting to the suite of comprehensive, executable specifications is what it's all about. For new code, that's easy. I just don't write any behavior before I've written a test. For legacy code, it can be more challenging. However, once I've attained the right body of tests for some code, I can refactor with impunity.

I don't care if my changes are proved to be transformative because, with NCrunch, I'm always about three seconds from finding out whether or not they were safe. For me, the focus is on creating an environment where refactoring is always safe regardless of how disciplined an approach I take.

The right conditions make certain problems irrelevant

This difference in emphasis is interesting to me. For one thing, they both have a common ancestor: culture. Neither of these methodologies can be installed without a fertile culture. For another, they both work.

A lot of people would look at two things that work and ask "which one works better?" A seemingly-natural impulse for us is to make two ideas compete so we can choose a winner. My inclination is to find a way to combine them into something new - a third option that keeps the best benefits and leaves behind the worst drawbacks.

I've been experimenting with applying discipline-focused refactoring to my own work. To be clear, I'm not giving up what I already do. I'm just adding his style to the way I already work. I'm not sure it's speeding me up but it's also not slowing me down and I've only just begun to practice it. With a few more weeks, familiarity will develop and it may well be faster.

There's something interesting there. You can combine them (at least in one direction) without any slowdown. There's a compatibility, there, that implies they are complementary techniques.

Check-In Day

Jane started a new job at a new company in a new town.

She knew things would be very different from the way she had already done things. That was, in fact, why the new company hired her; they wanted her to teach them how she works.

Object-Oriented Performance

Long ago, in a land now distant to me, I worked for a very successful company.

They were the kind of company that wasn't successful because they were good at software development. They were good at something else and they had to do some software development to make that offering in the modern era.

I was brought into one team by a friend of mine in order to change their thinking. Years later, I heard they still reference me as the reason why they write tests first.

How Can I Test this Code?

Early in a test-driven development transition, a lot of people want me to make TDD work with their code.

"What you showed me was fine...great, even...but how can I make this work with my existing code?" they ask.

When we go look at their code, most of the time the answer is "You can't and that's a good thing".

My Pre-TDD Years

When I was initially exposed to test-driven development's precursor, test-first programming, I immediately sensed the value.

Yet I didn't take the leap, right away. It required a change in my mindset and in my habits. Those things were hard and thus deferred. So years passed with me saying to myself "I really should write the tests for this, first".

What broke me out of the rut was when a test engineer said "I really love your code."

Adopting the TDD Mindset by Altering Habits

Previously, I wrote that test-driven development is a mindset, more than it is a skill. It's easy to learn but it's difficult to adopt because you have to change how you see and think about software development.

One way to modify your worldview is to form an habit and allow that habit to gradually transform your perspective. That's exactly how I made my transition to being a test-driven developer.

How TDD Can Help with Design

Test-driven development can help you with your software design.

People who make this claim sometimes emphasize the fact that good designs tend to be easy to test. This mislays the active force and makes a very simple process sound almost magical.

The important factor is not that good designs are easy to test. It's that bad designs are hard to test.

Test-Driven Development as a Mindset

For what I consider to be a long time, I've been trying to help people adopt test-driven development. It always seems more challenging than it should be.

I think I might finally have identified the fundamental impediment: I'm trying to teach people something that cannot be taught, because it is not really a skill.