CST 438 - Week 5

Unit Testing vs. End-to-End Testing

A unit test targets a specific behavior, usually a method or an API, and should be limited to a single process. Unit tests abide by the FIRST principles: Fast, Isolated, Repeatable, Self-validating, and Timely. 

• Fast: If unit tests are not fast, they will slow down development time. If a test takes 5 minutes to run and must be run multiple times a day, it will lead to reduced productivity.
• Isolated: Unit tests do not depend on the results of other tests, and they focus on one specific behavior.
• Repeatable: Tests should produce the same result each time they are run. 
• Self-validating: The tests themselves verify whether they have passed or failed. There should be no manual interpretation of results because it takes too much time.
• Timely: Unit tests should be written alongside the code they test. The sooner code is tested, the better.

End-to-end (E2E) tests, in contrast, target a larger part of the system. These tests focus on user workflow and simulate real-world use cases. They use real browsers and databases instead of mocks. This type of testing is important because it expands test coverage (rather than focusing on a single behavior) and verifies that an application behaves correctly in response to end-user activity. However, end-to-end tests are more difficult to implement and can be time consuming.

CST 438 - Week 4

Textbook Ratings

Software Engineering at Google: 4

I am rating this book at 4 because it is very informative and gives a lot of insight into Google's software development processes. Even though it focuses on a single company, knowledge gained from this book can be applied to virtually any software team. Anyone looking to improve coding practices and increase productivity will find it useful. However, the chapters are very long and can be difficult to get through in one sitting. 

Full Stack Development: 3

This book does a good job of introducing the basics of full stack development. However, I noticed that in many cases the pages do not have much information and the authors just paste code. Some of the code is not even applicable to what we're doing in this class, and modifications must be made. It does provide a good starting point, however. I plan on seeking out a different source if I need to learn more about this topic.

CST 438 - Week 3

How does React compare to other frameworks you have used for front end development? 

The only other framework I recall using is jQuery. While JQuery makes object selection and manipulation easy, I've always preferred using vanilla JavaScript (which is necessary for working with React). Creating user interfaces seems really easy with this framework too, and the interfaces are fast and responsive. React seems to be used by a lot of companies, and I often see it listed as a requirement in job postings. It is likely that I am going to be using it again in the "real world" and should increase my proficiency. 

CST 438 - Week 2

In your own words, what is TDD about?

Test-Driven Development (TDD) is an approach to software development that uses the Agile process. It differs from traditional unit testing because the tests happen before the feature code is actually written. First, a failing test is created for an unimplemented feature. Next, the minimum code required to pass the test is written. Finally, the code is revised and improved (while still being tested along the way). This cycle repeats until all requirements are met.

What is a MOCK (also called DOUBLE) and how does it help in unit testing?

In unit testing, mocks are special objects that are used to imitate the behavior of a real object in our code. Sometimes it is not practical to use real objects for testing, like when there are external dependencies. A mock object does not depend on the state of any external objects and can return specific results based on predetermined inputs. A mock object is only useful for its associated unit test. Using mocks helps the unit testing process by allowing developers to write more concise unit tests.  

CST438: Week 1

Back at it!

It's been over 6 months since I was assigned a blog post. I can't say I am excited about it, but I can't really complain. It's not very stressful unless I forget about it until right before it's due... like right now.

What did I think Software Engineering was about before I started this course?

I didn't have much of an idea. The name alone is intimidating. I've been programming for a long time, but I've never done any kind of "engineering" before. My only guess was that we'd be learning new technologies to speed up the process, and we'd be focusing a lot on the software life cycle. 

After the first week, in what way has my concept of Software Engineering changed?

Now that I've gone over the introductory material, I know that the main differences between programming and software engineering are longevity and scale. Programs can be written by individuals and may only have a lifetime of a few hours or days (such as a homework assignment). Software engineering involves teams of people (usually 2-pizza size) working on long-term projects. Since those projects are long term, there is more to consider up front (such as how to adapt to code deprecation or changing requirements). 

Another issue that is hard to deal with in long-term projects is Hyrum's Law, which states that any change you make to your code (no matter how innocuous) will break someone's code somewhere. Even unintended, undocumented behavior from your code can be an important part of someone else's code. All changes must be necessary and carefully thought out. However, I don't think we should feel too guilty about breaking other people's code with a useful update.