See Michael Feathers’ definition A test is not a unit test if: It talks to the database It communicates across the network It touches the file system It can’t run at the same time as any of your other unit tests You have to do special things to your environment (such as editing config files) … Read more
Testing only one thing will isolate that one thing and prove whether or not it works. That is the idea with unit testing. Nothing wrong with tests that test more than one thing, but that is generally referred to as integration testing. They both have merits, based on context. To use an example, if your … Read more
With implementing a custom interface you are already on the right way. I take it you use the following advise from the golang-nuts thread you’ve posted: type Clock interface { Now() time.Time After(d time.Duration) <-chan time.Time } and provide a concrete implementation type realClock struct{} func (realClock) Now() time.Time { return time.Now() } func (realClock) … Read more
This is not the most common thing to do, but still common enough to have its own name. This technique is called Guard Assertion. You can find a detailed description of it on page 490 in the excellent book xUnit Test Patterns by Gerard Meszaros (highly recommended). Normally, I don’t use this pattern myself, since … Read more
The simplest way to do this is to just use the useValue attribute and provide an Observable of the value you want to mock. RxJS < 6 import { Observable } from ‘rxjs/Observable’; import ‘rxjs/add/observable/of’; … { provide: ActivatedRoute, useValue: { params: Observable.of({id: 123}) } } RxJS >= 6 import { of } from ‘rxjs’; … Read more
Take a look at Markus Kuhn’s UTF-8 decoder capability and stress test file You’ll find examples of many UTF-8 irregularities, including lonely start bytes, continuation bytes missing, overlong sequences, etc.
Your test could be: it(‘should emit on click’, () => { const fixture = TestBed.createComponent(MyComponent); // spy on event emitter const component = fixture.componentInstance; spyOn(component.myEventEmitter, ’emit’); // trigger the click const nativeElement = fixture.nativeElement; const button = nativeElement.querySelector(‘button’); button.dispatchEvent(new Event(‘click’)); fixture.detectChanges(); expect(component.myEventEmitter.emit).toHaveBeenCalledWith(‘hello’); }); when your component is: @Component({ … }) class MyComponent { @Output myEventEmitter … Read more
Readability is more important for tests. If a test fails, you want the problem to be obvious. The developer shouldn’t have to wade through a lot of heavily factored test code to determine exactly what failed. You don’t want your test code to become so complex that you need to write unit-test-tests. However, eliminating duplication … Read more
Designs like MVP and MVC typically try to abstract as much logic out of the actual GUI as possible. One very popular article about this is “The Humble Dialog Box” by Michael Feathers. Personally I’ve had mixed experiences with trying to move logic out of the UI – sometimes it’s worked very well, and at … Read more
The fundamental difference between the three strategies you’ve listed is whether or not the test code is in the same package as the code under test. The decision to use package myfunc or package myfunc_test in the test file depends on whether you want to perform white-box or black-box testing. There’s nothing wrong with using … Read more