Person was initialized with a name other than "fetus", your test would fail.. but your test has several reasons for failing and that's what makes it not-so-good: that same test would also fail if a
Person was "born" with a child (!) or if
age defaulted to 1, or if the welcome to this world string was different.
I've never written a unit test with JS, but I believe the following would apply:
- Name your test method so that anybody (including non-technical) reading it (the name) knows exactly what is being tested.
- Arrange the dependencies of your SUT (that's System Under Test). Set up /configure your mocks, define what the expected outcome should be.
- Act upon your SUT (i.e. call the method you want to test). Pass in your mock dependencies, retrieve the "actual" result.
- Assert - verify that you get expected results, i.e. make the test pass, or fail.
In this particular case, I'm not sure what's being tested exactly - you're merely verifying that the
person object was initialized with the expected default values? I guess it's ok.
Unit tests should be testing that the code does what it's supposed to be doing.
As I said I've never written a test with JS, so this example is C#:
public void ShouldReplaceCommaWithEmptyStringInProductDescription()
var testDescription = "Product,Description";
var data = GetValidMockRecord();
var values = data.Split(',');
values = testDescription;
data = string.Join(",", values);
if (!testDescription.Contains(",")) Assert.Inconclusive("testDescription must contain at least one (1) comma (,).");
var sut = new EdiParser();
var expected = testDescription.Replace(",", string.Empty);
var result = sut.Parse(data);
var actual = result.ProductDescription;
I don't think the language is a barrier: as you can see I'm asserting in my arrange section and making the test inconclusive if the test data would make the test, well, inconclusive. Then in the actual assert section I'm only testing one thing, and this is what unit testing is really about.