# should-up

> De-clutter your unit test descriptions

Latest version **1.0.0** (published 2017-04-25) · Apache 2.0 license · 0 weekly downloads

## Install

```sh
npm install should-up
pnpm add should-up
yarn add should-up
bun add should-up
```

Provides the command `should-up`.

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 1.0.0 |
| Published | 2017-04-25 |
| First published | 2017-04-25 |
| Weekly downloads | 0 |
| License | Apache 2.0 |
| TypeScript types | none |
| Module format | CommonJS |
| Dependencies | 2 |
| Known vulnerabilities | 0 |
| Install scripts | no |
| GitHub stars | 168 |
| Author | Henry Smith |
| Maintainers | henryspotify |
| Keywords | tdd, cleanup |

## Links

- npm: https://www.npmjs.com/package/should-up
- Repository: https://github.com/spotify/should-up
- Homepage: https://github.com/spotify/should-up#readme
- Issues: https://github.com/spotify/should-up/issues
- npm.io page: https://npm.io/package/should-up

## Dependencies (2)

- [command-line-args](https://npm.io/package/command-line-args.md) ^4.0.2
- [recursive-readdir-sync](https://npm.io/package/recursive-readdir-sync.md) ^1.0.6

## Recent versions

- 1.0.0 (latest) — 2017-04-25
- 0.0.0 — 2017-04-25

## README

Should Up
=========

Remove all those "should" prefixes cluttering up your JS unit test descriptions!

When you run `should-up`, it'll go through all the files in the directory you specify, cleaning up as many test descriptions as it can. Afterwards, the changes should look something like this.

<table>
<thead><th>Before</th><th>After</th></thead>
<tbody>
<tr>
<td>

<pre><code>describe('TodoApp', () => {
  it('should store reminders in local storage');
  it('should set reminders as done when clicked');
  it('should sync with the cloud');
});
</code></pre>

</td>

<td>
<pre><code>describe('TodoApp', () => {
  it('stores reminders in local storage');
  it('sets reminders as done when clicked');
  it('syncs with the cloud');
});
</code></pre>
</td>

</tr>
</tbody>
</table>

Installation
------------

```bash
npm install -g should-up
```

Usage
-----

```
should-up /path/to/your/tests
```

Rationale
---------

As you can see from the following highly scientific table of data, there's a pretty strong negative correlation between the readability of your test descriptions and the amount of meaningless filler in them.

<table>
<thead>
<th>Readability</th>
<th>Amount of meaningless filler</th>
</thead>

<tbody>

<tr>
<td><strong>Total Disaster</strong><br />⭐️</td>
<td>
<pre><code>Widget
  ✓ should always correctly contain a button whenever appropriate
  ✓ should always correctly dispatch an event on click whenever appropriate
  ✓ should always correctly show the name of the user whenever appropriate
  ✓ should always correctly show the type of widget  whenever appropriate
</code></pre>
</td>
</tr>

<tr>
<tr>
<td><strong>Still Very Bad</strong><br />⭐️⭐️</td>
<td>
<pre><code>Widget
  ✓ should always correctly contain a button
  ✓ should always correctly dispatch an event on click
  ✓ should always correctly show the name of the user
  ✓ should always correctly show the type of widget
</code></pre>
</td>
</tr>

<tr>
<td><strong>You Are Here →</strong><br />⭐️⭐️⭐️⭐️</td>
<td>
<pre><code>
Widget
  ✓ should contain a button
  ✓ should dispatch an event on click
  ✓ should show the name of the user
  ✓ should show the type of widget
</code></pre>
</td>
</tr>

<tr>
<td><strong>All Killer No Filler</strong><br />⭐️⭐️⭐️⭐️⭐️</td>
<td>
<pre><code>Widget
  ✓ contains a button
  ✓ dispatches an event on click
  ✓ shows the name of the user
  ✓ shows the type of widget
</code></pre>
</td>
</tr>

</tbody>
</table>

Anyway, when we start everything with the word "should", it sounds like we're not really 100% sure about what our code does.
Like maybe we're even a little bit pessimistic that it works at all, but we're crossing our fingers and hoping for the best anyway.

> Well... it _should_ dispatch an event on click, but I dunno.
> Just... look, you can run it if you want, but don't come to me if it breaks is all I'm saying.

When you say something like `it('dispatches an event on click')` instead, it's literally a more enjoyable thing to write.
It makes you feel like you're more certain about what your code's doing, and also more proud of your concise new unit test descriptions.

Contributing
------------

This project adheres to the [Open Code of Conduct][code-of-conduct].
By participating, you are expected to honor this code.

License
-------

[Apache 2.0](LICENSE)

[code-of-conduct]: https://github.com/spotify/code-of-conduct/blob/master/code-of-conduct.md

---
_Source: https://npm.io/package/should-up · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._