Capstone Prep Week 2: Team Intros, Testing and Redux
As Capstone prep continues I've noticed a two-fold sense of both progress and growing confidence: progress towards definitive mileposts (the start of Capstone and the start of a new career), and the growing sense that yes, I can do this.
In the almost two years from when I first enrolled in Launch School to finishing its Core Curriculum, there was always this sense that a new career was out there at the end of the journey; I just didn't know when that would be given the self-paced, mastery-based nature of the program, which has no time-based mileposts other than those that might be self-imposed. And it's also certainly the case that one is just an aspiring software engineer while going through the program, rather than a software engineer full stop.
But by this point things are qualitatively different: I now have definitive mileposts in sight as well as a sense that, yes, finally and after all this time, I can actually change my professional title to software engineer.
Meeting My Team
This week I had the opportunity to meet my teammates for the first time. Launch School has a very active Slack community which gives the opportunity to meet other students while making one's way through the program, but I had never come across any of my teammates previously. And not knowing anyone with whom you're going to be spending a great deal of time over the next several months brings a bit of curiosity (maybe even some anxiety) with it– Will we get along well? What if I'm not as good as my teammates? What if we have different levels of motivation? etc etc.
All in all, we had a productive meeting getting to know each other, and I think everything will work out just fine. Sure, we may hit some inevitable snags along the way as we learn to work together, but that's not unexpected when forming a new team. The most important thing is that it takes a certain level of excellence to complete the Core Curriculum with high enough marks to satisfy Capstone's admission requirements, which we've all attained, and a willingness to learn together and support each other through these next several months.
Testing, Testing and More Testing
This week I was knee deep into JavaScript testing on both the backend and the frontend, learning about unit, integration and end-to-end (E2E) testing.
As can be gathered from the name, unit testing focuses on isolating individual components or functions (i.e, units) of an application. This means that a test completely isolates a single part from the rest of the application, limiting or removing any side effects (like querying and manipulating a database) as much as possible. Since the backend application we were working through was essentially an API for querying a database, our course opted for integration tests over unit tests, since there really wasn't any functionality to our backend app that didn't also involved querying a database.
To test our React-based frontend we designed unit tests to test the rendering of individual components. One point of interest is that in testing how React components are rendered, we learned how to mock user input like clicking a button or entering text into an input field using the testing utilities from @testing/library. Pretty cool…
To further test our React frontend we also learned how to use Cypress for complete end-to-end (E2E) testing. In contrast to unit tests, which isolate and test single components, or integration tests which test multiple components together, E2E tests test the entire application as a whole. Learning about Cypress (and E2E testing as a whole) was probably the most interesting part, as tests are run in the browser and mock the user experience from the user's perspective. In other words, just as we were able to mock user input when designing unit tests for individual React components, we created tests in Cypress that mocked not only user input but user flow through the application we built (a simple note logging app). To boot, Cypress also has a nice GUI that displays the testing flow in the browser as it happens, which makes poking around an application to check the state of components at specific times rather easy.
State Management with Redux
When I was first learning React during the 'downtime' I had between Core and the beginning of prep, one of the issues I ran into as I was building my own application was how unmanageable managing state can become as the depth and complexity of an application grows. As that added complexity continues to pile on top of itself, all of sudden you've got all sorts of state to manage, while passing all sorts of state through all sorts of component props, while simultaneously trying to avoid unnecessary re-renderings. It gets a bit messy, to say the least.
If only there were a way to simplify state management…
Well hello there, Redux.
Redux is one of those things I really wish I had known about earlier. The beauty of it is that it abstracts the entirety of state management to a single JavaScript object called a store. So rather than leaving it to components within an application to manage state, all aspects of an application's state are now managed in a centralized location, the Redux store. From there, components simply hook into the store whenever state needs to be updated or retrieved.
Finishing Up Full Stack Review
This week is a bit busier than usual, with Thanksgiving coming up and two kids home for fall break, so time for Capstone prep is in short supply this week. Plus, I'm moving soon, which I also need to start prepping for this week, which compresses available time a bit more as well.
All of that said, I've got two more units (React router, custom hooks and Typescript) to finish in order to move to the next part of prep, which focuses on version control and cloud networking. I'd like to finish these two units this week, but given the aforementioned issues with my schedule, I'm not sure that'll happen.
But as always, we press forward, doing our best…
This article is part of a series writing about my experience going through Launch School's Capstone program.
Comments