-
YAGNI – YOU AREN’T GONNA NEED IT! WHAT DOES THAT MEAN FOR SOFTWARE?
Never write a single line of code before we really know that we need it. Don’t rely on experience from other systems we’ve written. A new project is never an exact copy of the old one, or there wouldn’t be a need for it. And a software project always changes the specifications during the process. Two facts that tells us that we have to wait to write the code until we really know that it is necessary. Or we will write code that we Aren’t Gonna Need. Waterfall or Ad Hoc? Neither! All software is developed with a goal in mind. An end product. A vision of what we want…
-
HOW TO CREATE A TEST FIXTURE
A test fixture is used to:● Make the code less brittle. We isolate the construction from all the tests and only do it in one place, so when we add a new parameter in the future, we only have to change the test code in one place.● Makes the job of writing tests easier, we write less code because we only call a function that creates the instance, instead of writing the entire construction with all the parameters in every test.● Make the code DRY (Don’t Repeat Yourself). We only do the construction, the newing up, in one place. The code Moq is used in this example. Obviously, there’s nothing…
-
HOW DO I WRITE A UNIT TEST THAT IS READABLE? DESIGN PATTERNS IN TESTS.
Writing unit-tests is not only about having a safety harness that catches the bugs that we create. It is just as much about making it easy for us to find the bugs. We want to write the tests in a way that they point us to the bug with as little effort from our side as possible. We want the tests to do as much debugging for us as it can. And of course, there are design patterns for this too. Code is never finished. We always add more features, change things, or just refactor. It’s part of our normal workday. But changing tested and delivered code is risky. Code…