Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.

https://en.wikipedia.org/wiki/Test-driven_development

From a couple weeks ago, my team finally started coding for our capstone project. For those weeks, my task was to create backend API endpoints. I followed Test Driven Development (TDD) to create those endpoints as I already knew the requirements for the endpoints.

This week’s plan was to create four endpoints below for our “A Dating Application for Animal Adoption” app.

I followed below six steps to implement those endpoints.

1. Write a unit test for one endpoint
2. Write the bare minimum of code to pass the test from step 1
3. Run all the written tests
   • If tests all pass, return to Step 1
   • If the failing test is still failing, return to Step 3
4. Evaluate and refactor the code as necessary to avoid duplicate code
5. Stop development after adding “enough” tests and tests all pass

//Example Unit test by using npm supertest library
it('POST /shelters responds 415 (incorrect content-type)', () => {
    return supertest(app)
      .post('/shelters')
      .send(
        "shelterName:Shelter Portland1"
      )
      .set('content-type', 'text')
      .expect(415, "Incorrect content-type.")
  });

TDD helped to avoid duplicate code since I wrote a small amount of code at a time to pass the tests. Also, I was confident that my code worked as expected. When I refactored the code, it was also easy to verify if my changes worked as expected. On top of that, if my teammates changed something, they don’t need to write any test cases. The tests are already in the code base and it is reusable any time.

I haven’t tried TDD at work nor previous projects, but I am glad that I used it for this project. To create API endpoints, there are other useful tools such as Postman, but TDD is also very easy to use and it is highly recommended if you have a chance to try it.

I believe most of the students who are attending OSU Online Computer Science Postbaccalaureate Degree program are working full-time. A Georgetown University report shows that 40% of undergraduates students and 76% of graduate students work full time while attending school. On top of that, about 20% of all working students have family to take care of. If you are one of many, like me, you know that managing work and school is challenging. Here are some tips that helped me to get through the last two school years.

Set dedicated study time

Creating a dedicated study time is your first step to successfully manage work and school. I am sure that everyone is tired after working all day and wants to go sit down on a couch as soon as they finish working. It happened to me too. I wanted to take a nap everyday after finishing my work, but having a dedicated study time helped me go back to my desk and keep studying everyday.

Create a schedule and stick to it

When the classes start and the syllabuses are posted, make sure to check the class schedule. The first week is usually light, and it’s the best time to create your personal schedule by figuring out the volume of reading materials and assignments.

For example, in my previous term, I was taking two classes that required a lot of time. The first class, let’s call it Class A, had about five textbook chapters and one programming project assignment every week. Class B also had about five chapters and one quiz every week. On top of that, Class B had labs and programming projects every other week (busy!). The course material opened on Sunday and assignments were due next Monday. How did I handle this amount of school work? I created a schedule like below and stuck to it.

• Sunday: Rest day and review the next week’s materials
• Monday: Finish reading material for Class A. Start working on the programming assignment for Class A (complete at least 30% of the project).
• Tuesday: Finish reading material for Class B. Start working on the programming assignment or lab for Class B (complete at least 30% of the project).
• Wednesday: Study materials and submit a quiz for Class B. + programming assignment for Class B.
• Thursday: Programming assignment for Class A or B.
• Friday: Programming assignment for Class A or B.
• Saturday: Backup day for school work

Every week, I started working on the programming projects as soon as I finished reading the materials. By starting the projects right away, I was able to know how difficult they were and how many hours I should spend on them each day. At the same time, I tried to finish small assignments right away so that I could focus on those programming assignments.

I know that everyone has different style of studying but the key is to create a schedule that works for you and stick to it. It will reduce stress and make it easier to manage school work.

Treat yourself

Working full-time and going to school is stressful. Make sure to have a re-charge day whenever possible. If not, take PTO and go on vacation during the summer or winter break! Going to a gym a couple of times a week helped me forget about most of the stress from school, and having a little treat from Yi Fang Tea on the weekend always made me happy. Find something that makes you relax and happy every week, and you should be able to keep going until the end of the semester!

Don’t give up

Lastly…don’t give up! I thought about quitting this program so many times in the last two years, but I am glad that I didn’t. I only have a couple of months left and am looking forward to my graduation!

Since this Capstone project is a group project, I thought it would be nice to talk about some important tips to effectively work in a group.

Set clear expectations

One reason some groups fail is that the team members don’t know what they are responsible for and what they need to work on. If there are no clear expectations, they might be working on something slightly (or completely) different than everyone else. This lack of coordination can lead to technical debt and adjustments when action items should have been winding down. You can avoid this by having a good project plan. In the project plan, you should at least have three important items: 1. detailed description of your initial thoughts on the structure of the project, 2. a thorough and complete description of what each team member will be accomplishing for the project and 3. some graphical examples for the project. The clearer the plan is, the fewer misunderstanding your team members have. Also it is a good way to know if your project is on track or not.

Set deadlines and stick to them

Once a good project plan is created, stick to the deadlines. To make sure that you can meet the deadlines, divide major action items into smaller tasks and work on those. Sometimes individual items have multiple dependencies and would otherwise block downstream tasks. If you can’t hit a deadline, it’s important to notify your team members as soon as possible. Also, project management tools like Asana, Jira, Pivotal Tracker, and Trello make schedule management easier. Not only you can see your project progress and deadlines, you can also check other team members progress.

Communicate Clearly

Good, clear communication will help projects succeed. You might get delayed, but unexpected bugs or other events happen. Do not be shy and try to hide it. Be honest and seek some help from your teammates. When you chat or talk with team members, make sure that your communication is easily understandable. Other people should not have to guess what you are trying to say since it can cause future misunderstandings.

Respect team members

Always respect team members. You might finish your tasks quicker than other team members or might not agree with team members suggestions all the time. However, each member has different a life outside of work or school, and they might have different communication styles. Pointing out someone’s issues usually do not end well in group work. If you and your teammates are having issues, listen carefully and try to understand what the issues are and come up with solutions together. In the end, you would rather be someone who is patient and considerate rather than inpatient and selfish.

In my previous blog, I mentioned that I started my position as a software engineer intern at my company. I work as a full-fledged software engineer now, but was the path easy? No, it was very challenging.

Overwhelming codebase

When I started the position, all I knew was some introductory level C++ and JavaScript. However, at my work, we use the .NET framework with C#. Although, C# supposed to be easier than C#, those two languages looked very different to me. I thought I could write/read code okay because I was doing really well in my classes, but I realized that I was only familiar with a small amount of code that I worked on at school. I was completely overwhelmed at the size of the code base and all the downstream items that my changes could affect.

It took me one year to overcome this feeling. How did I do it? I just kept reading code and spent endless time trying to understand what was going on. I created several notes (most of them didn’t make sense because I was lost most of time) and I even created some diagrams to understand the flow of our systems. I wanted to ask questions to senior developers. However, they were all busy, and I didn’t want to bother them. I just kept on reading code everyday. The first half year was miserable. Facing all the unknowns was very frustrating, and the code base was just too overwhelming. Every once a while, things started to click. Once it started clicking, a lot of the code base started to make sense, and things became much easier. I probably spent too much time trying to figure out things by myself and often went down rabbit holes. Asking more questions would have probably sped things up, but I think that solving the issues on my own was integral to my development as a software engineer. Solving these unknown issues is now one of my strengths, and I am confident that I can figure out a lot of issues by myself!

Writing code that fits in with the existing code

One day, I was given a task to fix a small bug. I wrote several lines of code, tested it, and confirmed that everything worked nicely. I submitted the code for review. Soon after, the ticket came back and said “Hey, you can just call this method, ABC()”. All my work ended up just being a single line of code.

As mentioned in above section, reading the codebase definitely help learning the existing style and methods that we use, but I can’t spend all day reading and wasting time to just fix a small issue. To overcome this issue, I just started looking for similar functions. If I was working on scraping a website, I looked for another job that did something similar. I checked what libraries and classes they were using and imitated those. This worked pretty well for me, but we have some legacy code that I have to be careful with sometimes.

Another issue was that sometimes I thought I had a great fix, but I broke something else! This happened to me several times in the beginning, because I was only focused on the one issue that I was given. I wasn’t paying attention to the the bigger picture and how it would affect other processes. I did two main things to overcome this issue. First, I worked on understanding the reason behind the code. If I was dealing with data, it meant understanding what the data was for and how it was being used. Next, I checked what else was using the same method that I modified and verified that my change didn’t affect other sections of the code.

Ticket management

At the beginning, I easily spent hours working on one ticket, because I got stuck on a problem that I couldn’t figure out. I also felt like I would forget everything if I had to work on another ticket that was higher priority. Unlike the assignments from school, I usually had multiple ongoing issues or tickets that I needed to work on. I couldn’t work on one ticket all the time.

I was able to overcome these issues by implementing a few changes in my workflow. One crucial item was leaving good comments in the code and tickets. Another thing I found helpful was creating sub-tasks and dividing work as small as possible. Once a small task was completed, I would either keep working on the next issue on the ticket or move on to another ticket that was higher priority. Using this method, I was able to easily multi-task for some tickets, and it was easier to keep track of my progress.

Finally…

There were a lot more challenges that I faced in the beginning, and there are still a lot of things to learn everyday. Now, I can confidently say that I am a software engineer. Although, there are times that I feel like I am still not good enough. I think a lot of junior developer face the same issues that I had, and I hope this blog will make someone feel better in the future.

Welcome to my first post! My name is Eriko and I am OSU Post-Baccalaureate Computer Science student. I am originally from Tokyo, Japan and moved to United States in 2013 with only conversational level English. I was lucky enough to get my first job here in the US, but none of the opportunities that existed for me were challenging at that time. I was only able to find work for admin/operation positions that required a Japanese speaking ability. I wanted to have a job that was challenging, rewarding, and something that I could keep learning. That’s when I started to look into this computer science program!  

My CS journey started back in the summer of 2020, and it has been a long journey! Before I joined this program, I wanted to know whether I like programming or not, so I started learning programming by using freecodecamp. I soon got obsessed with their projects and spent many hours working on the various projects they offered. I completed the freecodecamp certification in four months and decided to move forward to join this OSU program. 

A little after I started the OSU program, I was able to get an internship position as a software engineer. The first year was very challenging, because I jumped into a large code base from with only my limited knowledge from freecodecamp and introduction to computer science I&II. I learned how to read and write good code every day. At the same time, I learned the fundamentals of computer science at school. Working on assignments was very time consuming, and it was challenging especially after being exhausted from work. However, it was interesting and rewarding to learn as I handled some real issues at work. That feeling gave me more energy and kept me learning everyday. For example, I was using an SQL database at work everyday but not everything fully clicked me until I took the introduction to databases class. I felt very fortunate that I was able to learn from school and work at the same time.

Now I work as a software engineer (no more intern!) and this is my last semester at OSU. I am excited to work on the last project, and I will continue to update my blog as my journey continues with my last quarter here at OSU.