In the article Introduction to Test Driven Development (TDD), Scott Wambler talks about what Test Driven Development (TDD) is, as well as many other topics related to it such as traditional testing, documentation, test-driven database development, and scaling TDD via Agile Model-Driven Development (AMDD). He also goes over why you would want to use TDD as well as some of the myths and misconceptions that people may have about it.
A basic description of TDD is that it is a development technique where you must first write a test that fails before you write new functional code.
A simple formula that Wambler included to help understand TDD is as follows:
TDD = Refactoring + Test-First Development (TFD)
Here’s a quick overview of TFD which he provided:
Reaction to Content
I chose to search for articles of this topic because I wanted to really understand how to properly perform test-driven development. For what project that I decide to work on next, I wanted to be able to follow an effective process so as to improve and avoid writing “spaghetti code”. I imagine there are other development methods that may be better suited for what I want to do, but this is one of the ones that I hadn’t had a great understanding of until reading this article. Hopefully I’ll be able to properly use this method to write clean, well-documented code in the future.
While I knew of TDD before reading this article, I never really took the time to actually learn how to do it. I think that this article was very useful in helping me understand what TDD is and what are the advantages of using it, but while I believe that I understand it conceptually, I’ll probably need to look up examples, maybe follow a tutorial to make sure that I don’t do it wrong and end up building bad habits.
One of the things in the article that I had some trouble understanding was when he referred to tests used in developer TDD as “developer tests” and that they were inaccurately referred to as unit tests. I think that he may be referring to unit tests as a section of tests included in developer tests as a whole, but I’m not completely sure.
In the blog post Writing Great Unit Tests: Best and Worst Practices, Steve Sanderson talks about the best and worst practices when writing unit tests. He goes over the true purpose of unit tests (each examining a unit of your code separately and as a whole cohesively working together to provide value that is more complex and subtle than the sum of its independently tested parts, not for finding bugs), as well as the purpose of integration tests (automate the entire system to detect regressions). At the end of his post, he also gives several useful tips for writing great unit tests, such as making each test orthogonal, or independent, to all other tests.
The reason I chose to talk about this blog post is because I think it’s definitely something that’s commonly overlooked by developers. As Sanderson said at the beginning of his post, “Even if you’re a brilliant coder with decades of experience, your existing knowledge and habits won’t automatically lead you to write good unit tests.” For people looking to get into software development, I think it’s important to learn how to write great unit tests early on so as to avoid having to clean up a self-inflicted mess in the future.
I found it interesting when he described the difference between unit tests and integration tests, as well as the problems that bad unit tests can cause. This image found in his post is useful for visualizing this:
The last section in which he gives practical advise for writing great unit tests is also something that I think will be useful in the future, although I think the formatting may have been messed up.
One thing that I have a hard time not necessarily agreeing with but understanding is how he said that unit testing isn’t for finding bugs. I think that, for example, if you were to make a change to the way a function performs its task (perhaps to optimize the code) while not trying to affect the end result, one of your unit tests failing because of this could be classified as “finding a bug.”
In the blog post Test Doubles — Fakes, Mocks and Stubs., Michał Lipski describes and implements three different types of test doubles: fake, stub, and mock, and the situations in which you would need to use them in your unit testing. He also provides useful examples for each of the three terms.
Here’s a useful image found in his blog that helps to understand the differences between the three:
Fake– object that has a working implementation, but not the same implementation as the ones in production. Usually they take some shortcuts are are simplified versions of the production code. This is useful because you’re able to do integration test of services without starting up a database or performing time consuming requests.
Stub– object that holds predefined data and uses it to answer calls during tests. This is useful when we can’t or don’t want to involve objects that would answer with real data or have undesirable side effects.
Mock– object that registers calls as they are received. This is useful when we don’t want to invoke production code or when there is no easy way to verify that the intended code was executed.
The reason I chose this blog post in particular is because the first time I was exposed to stub functions was earlier in my internship while working on unit tests, and at the time I didn’t have a great understanding of what their purpose was. I was recently reminded of them last week during lecture, so I decided that it’d be a useful topic to read about. At the time I wasn’t aware that there were different types of test doubles, so I found that the examples found in Lipski’s blog are really helpful in understanding the key differences between them, as they share many similarities and are likely to get mixed up. According to Lipski, misunderstanding and mixing test doubles implementations may influence test design and increase fragility of tests, standing in our way to seamless refactoring. So I think that this blog may be a useful resource if you were trying to write clean unit tests.
Before I started using WebStorm for my TypeScript project, I mainly used Microsoft Visual Studio or Eclipse. Sometimes you really take for granted being able to quickly perform certain actions using shortcuts for a specific IDE. While I could have continued to use Visual Studio for TypeScript, I figured it would be best to work with WebStorm given that my professor was using it. If I ran into a Visual Studio specific problem, he wouldn’t be able to help me, so to save any potential headache I decided against using it.
Of course, it’s not like WebStorm doesn’t have its own shortcuts. In fact, I found myself instinctively using shortcuts from Visual Studio that also ended up working in WebStorm, such as the comment shortcut (Ctrl+/). Knowing these shortcuts will likely save me time in the future, so I set out to find a list of useful WebStorm shortcuts.
Under each command she provided an explanation of the shortcut as well as a very useful visual of the command in action. She also provides a useful resource containing a list of all the WebStorm shortcuts for OS X, Windows, and Linux located here.
I hadn’t known about the majority of these commands. The “Code completion with replace” command is particularly useful because I recall auto-completing code while trying to replace a variable and ending up with both the new and original variables. “Multiple cursors” is one of the more interesting commands in my opinion. Being able to type the same code in multiple places at once, while pretty situational, would have been able to save me a lot of time, particularly on the HTML of some of my components. Also, Scratch files are a great idea that I had no idea even existed. Being able to create code samples or make notes directly in the IDE without affecting the rest of the project is a godsend. Not only that, but the Scratch files are saved in WebStorm if I need them later.
These commands, as well as the commands found on WebStorm’s key map reference card, are probably going to save me a lot of valuable time in the future, so it’s important to learn them as early as possible when using a new IDE.
Recently while working on our final project, my partner and I ran into an issue involving the positioning of courses on a schedule. We were trying to figure out a way to place elements (courses) on top of another element (the schedule). Naturally on our way to a solution, we stumbled upon absolute positioning. Using this we were able to place the courses in their correct positions on the schedule.
Even though that solution seemed to work, there was something about it that didn’t sit right with me. For whatever reason, the thought of using an absolute position on the page to place elements on another element just did not seem like a smart thing to do. What would happen if I added elements above the table?
Because the table uses the default position, its placement is based on its order in relation to other elements. However, the courses are using an absolute position relative to the page.
The solution to this is relatively simple, but not necessarily one of the most obvious solutions for those who are new to CSS.
static – positions the element statically, following the normal flow based on its order in relation to other elements, typically unnecessary.
relative – behaves the same way as a static element, except that if you give it a positioning attribute, such as: “left: 20px;”, it will be offset 20px left from its original spot.
absolute – causes the element to be completely removed the the document’s normal flow, no longer interacting with other elements. Absolute elements are positioned relative to the page, or to its parent assuming its parent is relatively positioned.
fixed – behaves similarly to absolute elements, however it won’t move when the document is scrolled or relatively to its parent element.
The key part of this is that absolutely positioned elements can be changed by added a relatively positioned element as its parent. Thus the simple solution to our problem was just to change the schedule (or table) to use a relative position, even though we weren’t making any changes to its position visually.
Not only does this change where the elements are positioned relative to, it also makes it so that if I were to set the width or height of the course’s container using a percentage instead of pixels, it would be relative to the size of the schedule instead of the page.
The reason I chose this blog was because it contained exactly what I was looking for: a way to place absolutely positioned elements relative to its parent.
In the second lesson of Shay Howe’s HTML and CSS tutorial, he begins going in more depth about HTML by showing which HTML elements are best used to display different types of content, how they’re visually displayed on a web page, as well as what different elements mean semantically.
Throughout the tutorial, Howe describes several different HTML elements and explains what their purpose is. He also displays a live demo of his examples which is very useful in understanding exactly what each element looks like visually. The list of elements that he describes and their purposes are as follows:
<div>: division – a block-level element that is commonly used to identify large groupings of content; helps to build a web page’s layout and design.
<span> – an inline-level element commonly used to identify smaller groupings of text within a block-level element.
<h1-h6>: heading – block-level elements with six different levels. These help to quickly break up content and establish hierarchy.
<p>: paragraph – blocks of text visually separated from adjacent blocks (i.e. vertical blank space, first-line indentation, etc.)
<b>: bold– stylistically offsets text.
<strong> – places a strong importance on text by bolding it.
<i>: italicize – conveys text in an alternative voice or tone by slanting it.
<em>: emphasis – places a stressed emphasis on text.
HTML5 introduced new structurally based elements in order to give meaning to the organization of our pages and improve structural semantics:
<header> – used to identify the top of a page, article, section, etc.
<nav>: navigation – identifies a section of major navigational links on a page.
<article> – used to identify a section of independent, self-contained content that may be independently distributed or reused.
<section> – used to identify a thematic grouping of content, usually includes a heading.
<aside> – holds content that is related to the main content around it, but not central to the flow of it.
<footer> – identifies the closing or end of a page, article, section, etc.
Howe emphasizes the importance of understanding the semantic difference of elements. For example, even though the elements <strong> and <b> both create the same bold text effect, they’re semantically different. The <strong> element is used to give strong importance to text while the <b> element simply stylistically offsets text.
The reason I’m writing about this topic because it’s very relevant to our final project. Prior to reading this I hadn’t even considered the semantics of elements. Also it’s useful to understand how to use each element. In the future I’ll be able to use what I learned to better organize pages and improve its structural semantics. I’ll also be able to apply this to my final project, so this lesson has been very useful to me.