# Developing a unit in Dusk

Let's imagine that you want to create a new unit called "lib/foo", how would
you go about that? First of all, you need a Dusk with a [io/grid] set up. This
is required for [text/ged], which we'll need to edit source files.

Let's begin by creating the unit:

  "foo.fs" p"lib" newfile drop

See [fs/core] for details. You now have an empty "lib/foo.fs" file. You'll write
automated tests for it, right? so let's create it too:

  "foo.fs" p"tests/lib" newfile drop

We can now add the boilerplate, which in Dusk is minimal. Let's open lib/foo.fs
in ed:

  edload<< lib/foo.fs

When you type "ged", you'll get a blank screen because the file is empty. You
can type "i" followed by "unit lib/foo", then press Return. You have your
boilerplate set, but the file is not saved yet. Press Shift+W to save.

Tests now. Press "q" to quit ged, then do:

  ?edload<< tests/lib/foo.fs

The "?" in front of "edload<<" is related to the multi-buffer feature of
[text/ed] (the "backend" of [text/ged]). It tells the editor to check of there's
already a buffer opened for that file, or if there's an empty buffer to recycle.
Otherwise, it will create a new buffer and load the specified file in it.

In our case, we only had one buffer with "lib/foo.fs" opened, so it will open
"test/lib/foo.fs" in a separate buffer.

When we run "ged", we'll have a blank screen, but we can cycle through our
buffers with CTRL+]. Cycle a bit to get the hang of it, then come back to the
empty buffer.

Press "i" then "needs tests/harness lib/foo" then Return to add the first line
of the test unit, then press "o" then "testbegin" then Return to add a line
underneath, then again with "testend". You now have a complete boilerplate.
Don't forget to save.

Test files can be ran individually with f<<, in this instance,
"f<< tests/lib/foo.fs". Units in the "tests" directory are also automatically
picked up by "f<< tests/all.fs".

We can verify that our test unit isn't mistakenly ignored by adding a line like
"0 #true" in it. Running the file will raise an assertion error, running the
full suite with "f<< tests/all.fs" will error out at some point.

So! boilerplate's done. Can we start coding? If you want, but if there's
significant work involved, chances are you'll trigger a footgun during your
experimentations and crash the machine. After a while, you'll get tired to
typing the same "setup" commands all over again. That's not the Dusk way.

The Dusk way is to configure your machine to "boot into" the work at hand so
that crashing is painless. Open "init.fs" with "edload<< init.fs" and add this
at the end of the file, after the prompt and everything:

  edload<< lib/foo.fs
  ?edload<< tests/lib/foo.fs
  : t word"tests/lib/foo.fs" f<< ;
  : r word"lib/foo.fs" f<< ; \ that's for reloading the unit after a change

This way, whenever you reboot, you're ready to hack into your stuff immediately.
Just type "ged" to edit files, or "t" to run your tests. When you make changes
to your unit, you run "r" so that its code in memory is freshened up. Of course,
that "boot" code can very wildly depending on what you're working on.

Alright, now you're ready to write your code!
