diff --git a/current/en-us/9. testing/1. components.md b/current/en-us/9. testing/1. components.md
index ef83774..043ac5c 100644
--- a/current/en-us/9. testing/1. components.md	
+++ b/current/en-us/9. testing/1. components.md	
@@ -27,13 +27,13 @@ Once you've got the library installed, you can use it in a unit test. In the fol
 
 Let's start with a simple custom element that we want to test:
 
-```HTML A Custom Element's View
+```HTML my-component.html A Custom Element's View
 <template>
   <div class="firstName">${firstName}</div>
 </template>
 ```
 
-```JavaScript A Custom Element's View-Model
+```JavaScript my-component.js A Custom Element's View-Model
 import {bindable} from 'aurelia-framework';
 
 export class MyComponent {
@@ -43,7 +43,7 @@ export class MyComponent {
 
 In order to test that the component renders expected HTML, based on what the view is bound to, we can write following test:
 
-```JavaScript A Custom Element Test
+```JavaScript my-component.spec.js A Custom Element Test
 import {StageComponent} from 'aurelia-testing';
 import {bootstrap} from 'aurelia-bootstrapper';
 
@@ -81,16 +81,13 @@ import {StageComponent} from 'aurelia-testing';
 
 ```JavaScript Staging The Element
 component = StageComponent
-  .withResources('src/my-component')
+  .withResources('my-component')
   .inView('<my-component first-name.bind="firstName"></my-component>')
   .boundTo({ firstName: 'Bob' });
 ```
 
 `StageComponent` comes with one property, `withResources`, that lets you start off the staging with a fluent API. `withResources` lets you specify which resource or resources for Aurelia to register.  It takes either a string for registering one single resource or an Array of strings for registering multiple resources. `inView` lets you provide the html markup to be run. This is just a standard Aurelia view where you can do all the data binding you are used to in a full-blown Aurelia application. `boundTo` lets you provide a test `viewModel` with the data that the view will get bound to. In this example, the staging of the component is done in Jasmine's `beforeEach` method in order to reuse the same setup for multiple tests.
 
-> Info
-> If you are using `karma` and your configuration already has a path for `'*': 'src/*'` set you may not need to use `src/`, and just `my-component`.
-
 Next, we come to the actual test where we call `create` on the `ComponentTester`. Create will kick everything off and bootstrap the mini Aurelia application, configure it with `standardConfiguration` (we will take a look later at how you can run with your own configuration), register provided resources as global resources, start the application and finally render your component so you can assert the expected behavior. In this case, we want to make sure our `firstName` property gets rendered correctly in the HTML by selecting the `div` tag via it's class name. We use `document.querySelector('.firstName');` to grab that and then check that its innerHTML is `Bob`. Next we call Jasmine's `done` function to tell Jasmine that the test is complete. Calling `done` is needed since the `create` method is asynchronous and returns a Promise.
 
 Finally, we call `dispose` on our `ComponentTester` instance. This will clean up the DOM so our next test will start out with a clean document. That's pretty much all there is to it. Easy right? Imagine doing the same assert with stand alone unit tests that run outside of Aurelia. It would be pretty difficult, especially for a more complex component.
@@ -182,7 +179,7 @@ describe('MyAttribute', () => {
 
   beforeEach(() => {
     component = StageComponent
-        .withResources('src/my-attribute')
+        .withResources('my-attribute')
         .inView('<div my-attribute.bind="color">Bob</div>')
         .boundTo({ color: 'blue' });
   });
@@ -397,4 +394,4 @@ waitFor(() => $('.firstName')).then((nameElement) => {
 
 ```JavaScript Waiting for an absent element with timeout
 component.waitForElement('.firstName', {present: false, timeout: 2000}).then(done);
-```
\ No newline at end of file
+```