In this issue from January 2017: A naming standard for unit tests; Scott Hanselman on everything you ought to know in 2017; Being mindful of your code; a hi-tech credit card; deliberate practice is more complex than 10k hours; and Joel Spolsky suggests developers are writing the future.
Sharpen the Saw is a somewhat delayed repost of a semi-regular newsletter of information I publish for the professional development of software developers. While targeted primarily at developers working with the Microsoft technology stack, content will cover a wider range of topics.
To subscribe, send me an email and I’ll put you on the list. Membership is moderated.
Techniques
Always a way to improve the code you write every day.
Naming Standard for Unit Tests
One of the real challenges when writing unit tests is in deciding what to test.
How do you decide on the correct granularity of test - on the one hand, you want tests that are fine grained so that each test is checking just one thing; on the other, you don’t want to be writing thousands of trivial tests that deliver no actual value.
Roy Osherove wrote the book on unit testing - The Art of Unit Testing. He suggests that each test should have a three part name - the thing being tested, the scenario and the expectation. By constraining each of these things to just a few words, clarity emerges … Eventually. Naming things is hard.
Sometimes the thing being tested is the entire class:
ImmutableStack_WhenItemsPushedInSequence_PopsItemsInReverseImmutableStack_WhenItemPushed_AlwaysPeeksItemJustPushed
Sometimes the thing being tested is a single method on that class:
Discard_WhenStackIsEmpty_ThrowsInvalidOperationExceptionDiscard_WhenStackHasOneItem_ReturnsEmptyStackPush_WhenGivenItem_ReturnsLargerStack
Read more on Naming standards for unit tests.
See also The Art of Unit Testing (Manning)
Software and Updates
A new or upgraded tool can be a beautiful thing.
What .NET Developers ought to know to start in 2017
Scott Hanselman writes about the state of .NET in 2017 and how it’s a much more complicated world than the one we knew just a couple of years ago. He’s written this post as a bit of a study guide and glossary, a starting point for those who want to learn more.
Being Professional
A great developer does more than just write great code.
Be mindful with your code
We all write code for our computers, instructing the machines to do the things that need to be done. If we’re smart, we’ll also write our code for other people, so that those who come after us can fix bugs and make changes with a minimum level of pain. In fact, I’ve found that (more often than not) the clueless dullard who needs to maintain my perfect code is none other than myself, in six months time.
Staying Secure
Staying safe online and writing secure systems are both harder than we think.
This high-tech card is being rolled out by French banks to eliminate fraud
Here’s an interesting idea - a credit card with an LCD screen on the back to display a rolling sequence of CCV codes instead of a fixed number.
Wildcard
Sometimes the answer is random.
The Myth and Magic of Deliberate Practice
It’s been written that it takes 10,000 hours of deliberate practice to become an expert in any one field. Like any gross simplification, this summary has limitations. It turns out that while practice is essential, it’s not sufficient. In this post, James Clear talks about strategies for success.
Video of the Week
Take some time to feed your mind.
Developers Writing the Future
As the keynote speaker at Slush 2016, Joel Spolsky talks about how software developers are writing the script for future. With stories about how Amazon optimizes for the height of its staff, how what you see on Facebook influences your mood, and what happens when software governs the way humans interact with each other, this is an interesting watch.
Comments
blog comments powered by Disqus