# The Action Pattern: Clean, Obvious, Testable Code

DevFeed: [The Action Pattern: Clean, Obvious, Testable Code](<https://devfeed.tech/articles/the-action-pattern-clean-obvious-testable-code-21871.md>)

Original publisher: [Read original article](<https://ponyfoo.com/articles/action-pattern-clean-obvious-testable-code>)

Author: ryan.glover@cleverbeagle.com (Ryan Glover)

Published: 2019-03-26T12:02:06Z

Content type: tutorial

Language: en

Sources: [Pony Foo](<https://devfeed.tech/sources/pony-foo.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Test-driven development](<https://devfeed.tech/topics/tdd.md>), [Development](<https://devfeed.tech/topics/development.md>), [mock api](<https://devfeed.tech/topics/mock-api.md>), [Mobile](<https://devfeed.tech/topics/mobile.md>)

Tags: [action-pattern](<https://devfeed.tech/tags/action-pattern.md>), [api](<https://devfeed.tech/tags/api.md>), [app](<https://devfeed.tech/tags/app.md>), [beginner](<https://devfeed.tech/tags/beginner.md>), [code](<https://devfeed.tech/tags/code.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [patterns](<https://devfeed.tech/tags/patterns.md>), [tdd](<https://devfeed.tech/tags/tdd.md>)

## AI overview

A tutorial introduces the action pattern for organizing complex JavaScript code. It uses a mock signup API endpoint for a mobile app and emphasizes explicit names, single-purpose functions, modular files, and test-driven development.

## Source excerpt

Let's convert a mock API endpoint for signing up new users in a mobile app into using the action pattern. When I first started writing software on the web, my code was a mishmash. Every project was loaded with unnecessarily long files and code left commented, thrown to the side of the road like an abandoned vehicle. The theme of the day was: unpredictability. Under ideal conditions--the happy path--I was able to make my code work. But what I couldn't do was make my code work consistently. One time through my code would work, then the next an anonymous 500 Internal Server Error would send me spiraling for days. I was able to squeak by, but the thought of having to continue answering emails from clients that read "this isn't working..." was a life I didn't want to lead. Taking off my beginner's hat, I started to see what other, more experienced programmers were up to. I'd heard about Bob "Uncle Bob" Martin in passing, eventually discovering his Clean Coders series. I was hooked. For the first time, he was answering questions others on my path hadn't. My primary question? "How do I organize complex code?" As far as questions go that was a ball of yarn, but over several videos he explained the parts I was missing: Using explicit names that can't be mistaken. Breaking your code into functions that do one thing. Using TDD (test-driven development) to guide yout work. Still green, some of this made sense and some of it didn't. The other problem was that Bob's language of choice was Java, not JavaScript. This meant that I was able to grasp what he was saying at a high level, but practically I was still stumped. Several iterations later... Eventually, what Bob taught started to sink in. As I gained experience, I slowly started to organize my code into a pattern (supported by a short list of rules): Any code that involves multiple steps should be moved into its own file/module. That file/module should be given a name that describes what those steps lead up to. Each step in that cod