Tag: TDD

Test-Driven Development (TDD) for the Non-Developer

When I got hired at the Credit Union as the Principal Software Developer, one of the major elements of the job is to define how software development is to be done at our Credit Union.

One of the things I frequently mention is that ever since I took over the Principal role at the credit union, we became a TDD shop.

What if you’re not a developer, and don’t know what TDD is about? What about if you just learned what the acronym TDD means?

Test-Driven Development (aka TDD) is a model of writing software defined by a particular practice; specifically, writing automated tests before writing the software itself.

This model directly contrasts with the approach of testing the software after it’s written.

It’s a very low-level coding process, sometimes called ‘Red / Green / Refactor’ (as the tools that execute tests typically indicate failed tests in red and passed tests in green.)

An Example workflow:

  • I write a test, and it initially fails. (RED).
  • Then, I write code that causes the test to succeed (GREEN.)
  • I write another test, that initially fails (RED).
  • And once the feature is complete, I refactor the code, while maintaining green passing tests.

This creates two products. The software itself, and the tests that verify its functionality.

Software is a complex piece of machinery that is easily and regularly changed, and those regular changes can cause unexpected flaws. Those tests, when automated to be as a part of the build itself, can help prevent those unintended errors. Updates to dependent systems are made easier, as software typically talks to a database, or services, or libraries, and those updates can be tested quickly, with minimal human intervention.

They also enforce a level of rigor in the system design. Developers build systems that are designed to be ‘tested’.

So why does this affect you if you don’t write code? As written, this seems like mainly a developer function.

The thing is, the technique is entirely a developer technique, but the TDD mindset is the true switch

Start with the tests. Ask yourself: how do you know the software/thing/system will work?

Say you’re a Business Analyst or a Product Owner on the fence about a feature, how will you know your feature will work? How will you know it’s effective?

You know what the feature is. You know WHY the feature should exist, and that’s normally enough to prioritize it (or not) on the backlog.

Take the TDD approach and start with the tests.

  • How will you know that the feature works?
  • What is the test that will prove the feature is valuable, and useful?
  • What would be a test that would NEGATE that assertion?

Or say you’re the analyst working on the requirements for that feature, and you’ve fleshed out all the details of the fancy new automation your team is working on. How will you KNOW that automation is adding the value that you think it should?

If you’re automating a bad process that shouldn’t even exist in the first place, could you tell?

If you’re saving the company money, how much, and how will you tell?

For a more concrete example, say you’re a UX designer. Many UX elements are discretely testable, but what about the UX being “intuitive”, or aligned with our UX strategy?

Is the information you’re presenting easier to understand, or harder?

How do you know?

Say you’re an executive, a director or VP, or even a C whatever O. You have a vision for your organization, and where we are going.

How do you know it’s working? What is the test that drives your decisions?

What is the test that lets you know your vision is communicated well, and that everyone is marching to those orders in the same direction?

Would you know when to turn around if you’re making a mistake? Or would that mistake have to linger a bit for you to know it exists?

Like software, companies and organizations are complex machines that regularly change, and those regular changes can cause unexpected flaws.

These examples have been presented in a series of questions, as this is fundamental to the TDD process I described above. Designing a code snippet, function, feature, automation, UX, or company with the tests-first helps define your knowledge, and the information you’re trying to get.

To sum up: Define your tests first. Define what you want, and how you’ll determine that you’ve gotten what you want. Define how you’ll measure your effectiveness and measure how you’ve achieved it.

Write your tests first.

P.S. For further reading about TDD for the Non-Developer, take a looksee at this post from IExtendable.

TDD in Fable and React – can it be done?

I’ve been working to evangelize F# through {Redacted} for about a year now. I started with tests, and the build server, using FAKE and using standard tools.

In one of our Dev org meetings today, a junior developer brought up his experience with Fable, after noting how much fun I was having and sharing while coding in F#.

His review was fantastic. He was using React, and comparing native Javascript versions to what F# was enabling him to produce, and the code was more terse and wonderful. One of the things you immediately notice about React components is that the markup is still quite messy, and there is certainly something “icky” feeling about combining your markup and javascript. With Fable, Elmish and React, you are simply calling functions, with no extra tags that you don’t need.

Fundamentally though, the debugging story wasn’t great, and the TDD story was equally difficult, as he couldn’t figure out how to immediately test against a virtual DOM in his Fable F# code. For now, I ask the community, how do you best do that? How do you test that the virtual DOM actually contains the react component in question? How do you test it? I have a feeling that in the next week or so, I’ll find out.