Previously, we've learned about how arrays work. We know that
elements onto the ends of arrays, and
pop() pops them off; similarly,
unshift() adds elements to the beginnings of arrays, and
shift() pulls them
Now it's time to put what we've learned to the test.
You might have noticed that our tests are looking for functions like
destructivelyAppendKitten() — what's up with that? (Rest assured, no kittens
will be harmed.)
We want to distinguish between actions that mutate ("change") their underlying
unshift()) and those
functions that leave those structures untouched.
In general, it's good practice to avoid mutating a program's state whenever possible. So we want to call out these methods as destructive, since mutating state means we don't always know what we're dealing with. Indeed, these mutations mean that we need to refresh the test environment after every test to make sure that we're not working with mutated data!
By contrast, we also have methods like
appendKitten(), which simply adds a
kitten to the end of the
kittens array and returns the new array, leaving
the existing array untouched. This flow is preferable to mutating state because
we have complete control over what's going into and coming out of the function.
Try to use methods like
concat() to return a new
array when keeping the original array intact.
Think of it this way: you're making a peanut butter and jelly sandwich. Would you rather work with a sandwich where someone had put an unspecified amount of peanut butter or jelly on the bread before you start making it (or, worse, where someone had taken a bite out of the bread), or would you rather start fresh?
Regardless of your feelings about stale peanut butter and jelly, we're going to state unequivocally that fresh sandwiches are preferable — and fresh functions (ones that don't mutate shared state) are preferable, too.
You'll notice that the first test asks for an array called
kittens, set to an
initial value of
["Milo", "Otis", "Garfield"].
In our test file, we're going to reset this array to your initial value after every test. Some of our tests manipulate arrays in place, and we want to be sure that we can get back to a blank slate between tests.
Why is a blank slate important? We want our programs to be predictable: this makes them more robust, easier to maintain, and less prone to bugs. One way to achieve predictability is by isolating our tests from one another, meaning that no test should depend on the outcome or process of any other test. That way, tests can run in any order and test known inputs and environments, rather than depending on other tests running first and modifying the entire environment.
Remember the workflow:
Read the errors; vocalize what they're asking you to do.
Write code, save, and repeat steps 1 and 2 often until a test passes.
Repeat as needed for further tests.
learn submit when finished!