You are currently browsing the Quick Tips archives.

NPM & Root Permissions

Tuesday, November 1st, 2016

When dealing with NPM Permissions, often times it can be tempting to resort to installing modules as root (sudo), especially when under tight time constraints; where troubleshooting such issues will only serve to delay your progress.

Admittedly, I have been guilty of this more often than I care to admit. That said, being as I always have the Broken Windows Theory in the back of my mind, I knew this workaround needed to be resolved as soon as I had a moment to dig into it a bit more.

Previously, I had followed the instructions from docs.npmjs; however, they focus more on installations of global dependencies, rather than local dependencies. Fortunately, after a few quick searches, it became apparent that by simply changing permissions to the ~/.npm directory, this issue could easily be resolved as, all that is needed is to change the owner of the ~/.npm directory to the current user (as opposed to root).

To do so, simply run the following:

sudo chown -R $(whoami) ~/.npm

Likewise, you can use your username explicitly; e.g.:
sudo chown -R efeminella ~/.npm

And with that, the issue can safely be resolved, allowing you to run npm install as expected without having to fallback to using sudo.

React-Bootstrap ES6 Imports

Friday, August 12th, 2016

When leveraging React Bootstrap, one important consideration missing from the documentation (or perhaps, simply not emphasized enough) relates to module access when using ES6 imports.

Specifically, in the context of React Bootstrap’s “convenience components” <Component.SubComponent> (e.g. <Modal.Body>), such imports must be made explicit as they can not be resolved against their parent components during transformations of ES6 imports to CommonJS modules.

For instance, one can not reference sub-components as follows:

During transpilation, the above reference will result in Babel (specifically, the babel-plugin-transform-es2015-modules-commonjs module) causing an upstream exception:

Property object of JSXMemberExpression expected node to be of a type [“JSXMemberExpression”,”JSXIdentifier”] but instead got “MemberExpression

Fortunately, the solution to the issue is rather straight-forward; simply import the sub-component explicitly via react-bootstrap/lib , for example:

With the above example, the previous conversion errors will be resolved, and all will be well again.

Overall, I actually prefer the explicit imports (though it would be more convenient if they were exported via ‘react-bootstrap’).

And so, for the time being, a minor nuance worth noting should you find yourself trying to diagnose this issue at some point.

Quick Tip: HTML to JSX Conversion

Tuesday, July 19th, 2016

Like many developers, at times I find the need to convert raw HTML to JSX. It was only after I found myself needing to do this a bit more frequently that I considered writing a quick tool to automate the task. However, like most things, I knew there must be something out there which handles this already, and as I suspected, there certainly is: HTMLtoJSX – a component of React-Magic which does precisely this.

So, if ever you need to quickly convert raw HTML to JSX, be sure to check out the online converter and, for more frequent needs, the converter is also available via NPM and can easily be integrated into part of an existing build pipeline.

IIFE in ES6

Wednesday, April 6th, 2016

TL;DR: In ES6, an IIFE is implemented as follows:


Unlike ES5, which is syntactically less opinionated, in ES6, when using an IIFE, parenthetical order matters.

For instance, in ES5 an IIFE could be written either as:

or

As can be seen in the above examples, in ES5 one could either wrap and invoke a function expression in parentheses, or wrap the function expression in parentheses and invoke the function outside of the parentheses.

However, in ES6, the former throws an exception, thus, one can not use:

But rather, the invocation must be made outside of the parentheses as follows:

As an aside for those who are curious, the syntax requirements are specific to ES6 and not a by-product of any particular transpilers (i.e. Babel, Traceur, etc.).

NET::ERR_CERT_INVALID Trick

Thursday, October 22nd, 2015

So here is an utterly ridiculous trick that may actually prove to be quite useful should you ever need it.

With recent Chrome updates, hosts which fail to provide a valid SSL certificate are blocked via a NET::ERR_CERT_INVALID error. This essentially is the result of a secure site failing to provide a valid SSL Certificate in some way. In Chrome, when this occurs, you will see a screen similar to the following:

NET::ERR_CERT_INVALID

Previously one could circumvent this by clicking on a link which would allow you to override the error. However, such links in current builds of Chrome are no longer provided.

Interestingly, the work around for this is simple, bordering the ridiculous. Just focus on the page and type “danger“. The page will then automatically refresh and load as if the certificate was valid from that point on.

Obviously you want to be mindful of this work around (e.g. only using it for known hosts, such as a dev environment, etc., as was the case in my example).

BDD/TDD Mental Models

Thursday, February 13th, 2014

Recently, I shared a simple 8-step procedure with my team which outlines some of the general questions I tend to ask myself when writing tests, even if, perhaps, only subconsciously so.

While quite simple in form, and somewhat obvious in process, this procedure helps to develop a useful mental model from which practical steps can be applied to common testing scenarios; which, in turn, helps to provide clarity of general design considerations, while also helping to guide specific implementation decisions.

First things First

Arguably, the single most important aspect of testing (and software development in general, for that matter) is to acquire a solid understanding of the problem domain; for, without having (at minimum) a general understanding of the problem one is intending to solve, important details are likely to be omitted which would have otherwise been considered, and thus, covered by our tests. Spend time understanding exactly what problem your code is intended to solve, then begin thinking about what to test for. Understand the Problem.

Small Steps

Once confident that a good understanding of the problem has been reached, we can then get started on writing our initial tests. Consider this as a first pass, if you will, whereas we are only concerned with getting our tests to pass in the simplest (typically, least elegant) way possible. The initial implementation code can be as raw (and ugly), as needed, as this can (and will) be addressed after our initial tests are passing. If we are writing tests against code that does not yet exist, then we will first write the implementation code (the code that is being tested), directly within the test case itself. Once the test passes, we can then refactor the code out from our test and into the SUT (code we are testing). If the code already exists (we are writing new tests against existing code), we still need to understand and consider the implementation of the code itself, and not just simply write tests against it. Reviewing and critiquing existing code is an excellent way of gaining a quick understanding of a given system. Seize initial opportunities. Start off slow.

Clean Pass

Once we’ve written our initial tests and they are passing, we can then safely go back into our new or existing implementation code and refactor it to our hearts content. If we break something, our tests will let us know. After all, one of the most rewarding aspect afforded by unit testing is the ability to refactor our code freely with little worry or concern that we will unintentionally break something without knowing. If something breaks, are tests will inform us. Tomorrow never comes in Software Development. Clean up as you go along.

Negative Tests

The most obvious tests to write are those which are against the things we are expecting the code to do. But what about if the code is used incorrectly? What if an argument is required and it is not provided, or it is of an invalid type? Does our code throw an exception? Does it simply return undefined? What should it do? These are all questions we should be asking ourselves once our expected test cases are passing. After that, we need to start thinking about ways to have our code appropriately respond to negative cases – we don’t want the entire app to become in an unpredictable state just because an uncaught exception was thrown due to some simple string formatting argument not being passed, etc.. Test the exceptional; Test the unexpected.

Stateless Tests

One of the most important considerations to make both during and especially after all of the above points have been considered, is the statelessness of the system while being tested. Always ask yourself, “Am I resetting the state of all my test’s dependencies back to an expected state?”. This is perhaps one of the most commonly overlooked, yet crucially important consideration to make. A good example illustrating why this is important can be found in the common scenario of a test that invokes a method which triggers an event. If any previously executed tests which handle the event have not been properly tore down (e.g. afterEach), the object will still exist; and thus handle the event. This typically results in a change in state, more often than not causing an unexpected error to be thrown. Always use set-ups (e.g. beforeEach) to configure your tests environment, fixtures, any dependencies your test requires to operate properly. If you are setting values on anything outside the context of your tests; always use mocks, stubs and tear-down methods (e.g. afterEach) to reset them back to an expected state. Remember, while your tests are not part of your applications source, they are certainly part of your projects source; this, in effect, requires them to be viewed as first class citizens; subject to the same quality design and implementation as project source. Tests will need to evolve and be continually maintained. Treat the test environment with respect; ensure you return it in a predictable state. Leave it the way you found it.

Continued Improvement

While the above description of Stateless Tests clearly states that the test environment should remain stateless, and thus “remain as we found it” prior to our tests, our actual implementations code should always be improved when improvements can be made; hence, The Broken Windows Theory is one we should all strive to live by. This especially holds true in the context of writing tests/specs against existing code. If the code is not up to par in any way – fix it. Ask yourself: “How easy was it for me to understand what this code does?”. “Is it documented in a meaningful way?”. “Would it be easier to understand if I added some quick examples?” (Often, adding examples is simple a matter of pointing to, or annotating the source with the test cases themselves). We can have the greatest, most elegant framework and foundation on which to build the greatest apps in the world, but if we allow ourselves to let our code quality degrade, our apps will gradually decay into chaos. Set a higher standard, and live by it. Leave the source better than you found it.

Meaningful Tests

It is quite easy to get caught up in the perceived quality of a system’s tests simply by measuring it against general Code Coverage metrics. This is a subject I have spoken to at length many times. While code coverage certainly has it’s purpose, and can be helpful, it is often not very reflective of reality. Judge your tests not by the number of test cases or units tested, but rather, judge based on the meaningfulness of each specific test case itself. Ask yourself “What is the overall value of this test?”, “Am I testing the obvious?” (such as a simple getter/setter). Focus on what’s important, test whats of most value first. This will afford one the satisfaction of knowing that if time constraints or something comes up which requires shifting focus to something else, the most important test cases are covered. Focus on what’s important.

Know when you are done

It is quite possible for one to go on refactoring beyond what is essential. As such, it’s important to know when you’re done. Some questions to ask yourself are: “Does the code do what it needs to do?”, “Is the code clean and understandable, performant, efficient, etc.?”. “Does it have adequate coverage?” If these questions can be answered in the affirmative, then you’re most likely done. Many times, it’s tempting to continually refactor; as the more one refactors, the more opportunities for further abstractions begin to arise. When confident that your most important objectives have been met, you’re done. No when to stop.

Concluding Thoughts

It is important to note that the above considerations are by no means exhaustive – and this is intentionally so; as each point is specifically intended to provide just enough guidance to sufficiently ask the right questions, and thus solve problems in a pragmatic manner.

Over the years, I have found that it can be particularly helpful for developers new to a specific domain, or new to TDD/BDD in general, to consider the steps listed above from time to time in a general, summarized form. After doing this regularly, it becomes second nature; engrained in one’s daily development process.

  1. Understand the Problem
  2. Start off slow
  3. Clean up as you go along
  4. Test the unexpected
  5. Leave the test environment the way you found it
  6. Leave the source better than you found it
  7. Focus on what’s important.
  8. No when to stop