CST 438 - Week 3

This was our third week in CST 438 - Software Engineering.

Reflection

This week we covered software testing (such as unit tests). I have had some limited experience with unit tests in previous classes, but not integration or E2E tests. Those classes also did not explain the importance of testing. It seemed like an extra, arduous step that I sometimes had to take with some coding projects. The reading for this week, both of which I summarized some of the main ideas below, did a good job at explaining why software developers write tests and how to write good tests. During the reading, I found myself thinking about how I could add tests to my personal projects to help improve them. This week we are setting up a group project on GitHub that will last for mutliple weeks. Currently the project is only going to consist of three empty repositories, but already I am thinking about how I will write tests for whatever my portions of the project end up being.
 
This week we also covered the basics of Git to help prepare us for our group project. I have used Git and GitHub regularly for a while now, but it was good to get a refresher on the basic Git commands, especially since I don't use some of them often. Even without using some of the commands, Git and GitHub have been incredibly useful in my creative projects, letting me easily copy my project to extra devices and sync my project across said devices. Part of what we covered involved merge conflicts. The lecture for this week covered a topic that I had been considering but have not run into, where a developer changes a portion of code that another developer was adding to in a way that doesn't cause a merge conflict but does cause an error. The example the lecture used was developer one changing a variable name while developer two writes more code using the original variable name. I think this shows that reviewing merges and pull requests beyond the presence of merge conflicts is important.

Professionalism and Test-Driven Development

This week we read an article titled Professionalism and Test-Driven Development, written by Robert C. Martin.
 
The article defines three core laws of Test-Driven Development (TDD):
  • You may not write production code unless you've first written a failing unit test.
  • You may not write more of a unit test than is sufficient to fail.
  • You may not write more production code than is sufficient to make the failing unit test pass.
Together, these laws create a loop where one writes a unit test that fails and then enough production code to pass the test.
 
The article describes the following benefits of TDD:
  • Flexibility: Developers can avoid breaking their code by repeatedly running unit tests after making small changes. This makes it easy to make changes to the codebase without changing its behavior.
  • Documentation: Each unit test focuses on a single point of functionality at a time. This makes reading unit tests useful for learning codebases, as each test will show you how to do a single thing.
  • Minimal Debugging: If a developer is following the three laws of TDD, then a failed unit test will be the result of code that was just added or changed, making finding the source of bugs easy.
  • Better Design: Unit tests focus on a single function or functionality at a time. This encourages the developer to decouple functions so that they can better pass unit tests. This in turn results in developers following OOP principles.

SAG Ch. 11 - Testing Overview

 
This week we read chapter 11 of Software Engineering at Google, which covers testing in software development.
 
The book gives the most basic definition of an automated test as:
  • A single behavior you are testing, usually a method or API that you are calling.
  • A specific input, some value that you pass to the API.
  • An observable output or behavior.
  • A controlled environment such as a single isolated process.

According to the book, an efficient development team sees all developers writing unit tests for their code, running the tests frequently, and prioritizing fixing code that fails the units tests, a process that sounds very similar to TDD.

The book describes the following benefits to the process that it described:

  • Less Debugging: Tested code has fewer bugs both when it is submitted, and throughout its existence.
  • Increased Confidence in Changes: Code can be refactored with confidence because its behavior is constantly being verified by tests.
  • Improved Documentation: Clear, focused tests can also function as executable documentation.
  • Simpler Reviews: The process of reviewing code is faster if it has thorough tests.
  • Thoughtful Design: If code is difficult to test, then it likely has too many responsibilities or difficult-to-manage dependencies. Making code easier to test involves decoupling it and giving it a better design.
  • Fast, High-Quality Releases: Teams can regularly and quickly release tested code with confidence.

According to the book, Google has defined three sizes of tests:

  • Small: Runs in a single process.
  • Medium: Runs on a single machine.
  • Large: Runs wherever they want. 
 

Comments

Post a Comment

Popular posts from this blog

Week 26

CST-334 Week 2 This week was our second week in CST-334, also known as Operating Systems. Operating Systems: Three Easy Pieces This week we read chapters 4-8 of our course textbook. Chapter 4: Processes This chapter discusses processes, which are running programs, and how the OS virtualizes the CPU to run multiple processes. Key Takeaways: The OS runs multiple processes by stopping and starting them during context switches. All OSs have APIs that processes use to interact with resources and the OS. To create a process executable code of a program must be loaded from storage onto memory. Processes can be running, ready, or blocked. The OS tracks data for each process.  Chapter 5: Process API This chapter discusses certain important aspects in Process APIs. Key Takeaways: The fork() system call creates a new process. The new process is identical to its parent process when it made the system call. The wait() system call allows a process to wait for another process, or its child proces...
Read more

Week 22

Image
 CST-363 Week 6 This is our sixth week in CST-363, also known as Introduction to Database Systems. Summary This week we read about integrating SQL into programs and other languages. We learned about some of  the differences between SQL and other languages and some of the ways to integrate SQL into a program, such as Embedded SQL and APIs. Then, we learned how to use an SQL API for Java called JDBC. Vocabulary Programming Languages Imperative Languages:  Contain control flow statements that determine the execution order of program steps. Two popular types of imperative languages are: Procedural Languages:  Composed of procedures, also called functions or subroutines. Most languages developed prior to 1990 are procedural. Ex: C and COBOL. Object-Oriented Languages:  Organize code into classes. A class combines variables and procedures into a single construct. Most languages developed since 1990 are object-oriented. Ex: Java, Python, and C++. Declarative Languages:...
Read more

Week 23

Image
 CST-363 Week 7 This week was our seventh week in CST-363, also known as Introduction to Database Systems. Questions Compare MongoDB with MySQL. What are some similarities?   Both MongoDB and MySQL are database applications. Both function similarly in fundamental ways, such as having tables/collections. Both are best used alongside a general-purpose coding language, such as through the use of an API.  What are some differences? MySQL uses SQL, while MongoDB uses Javascript. Because of this the two applications are very different to use. Using the two applications with Java works very differently also. MySQL uses relational databases, while MongoDB uses document databases. This results in the two applications acting very differently. For example, MySQL has strict schema, whereas MongoDB has flexible schema. When would you choose one over the other?     If the database needed to be very structured, or the structure was guaranteed, then I would use MySQL. If t...
Read more