To be fair, these weren’t the exact words that were used, but a view was expressed from the keynote stage at Directions last week along these lines. Frustration that developers now have to concern themselves with infrastructure, like Docker, and writing automated tests rather than “real” code.
I couldn’t resist a short post in response to this view.
If It Doesn’t Add Value, Stop Doing It!
First, no one is forcing you to write automated tests – apart from Microsoft, who want them with your AppSource app submission. Even then, I haven’t heard of Microsoft rejecting an app because it wasn’t accompanied by enough automated tests.
I’m an advocate of developers taking responsibility for their own practices. Don’t follow a best practice simply because someone else tells you it’s a best practice. You know your scenario, your team, your code and your customers better than anyone else. You are best placed to judge whether implementing a new practice is worth the cost of getting started with it.
AppSource aside, if you are complaining about the amount of time you have to spend on writing tests then you have no one to blame but yourself. Or maybe your boss. If you don’t see the value in writing automated tests then you probably should stop wasting your time writing them!
Automated Tests vs “Real” Code
Part of the frustration with tests seemed to be that they aren’t even “real” code. If by “real” code we are referring to the code that we deliver and sell to customers then no, tests aren’t real code.
But what are we trying to achieve? Surely working, maintainable code that adds value for our customers.
We might invest in lots of things in pursuit of that goal. Time spent manually testing, sufficient hardware to develop and test the code on, an internet connection to communicate with each other and the customer, office space to work in, training courses and materials, coffee. We’re not selling these things to the customer either but no one would question that they are necessary to achieve the goal of delivering working software. Especially the coffee.
Whether or not automated tests are “real” code is the wrong question. The important judgement is whether the time spent on writing them makes a big enough contribution to the quality of the product that you eventually ship.
I won’t make the case for automated testing here. That’s for a different post. Or a different book. Suffice to say, I do think it is worth the investment.
But We’ve Got a Backlog of Code Not Covered By Tests
One problem you might have is that you’ve got a backlog of legacy code that isn’t covered by any automated tests. Trying to write tests to cover it all will take ages. This frustration also seemed to be expressed by the speaker at Directions. It even got a round of applause from some of the Directions audience.
My response would be the same – you are best placed to make a pragmatic judgement. Of course it would be nice to have 100% code coverage of your tens of thousands of lines of legacy code – but if you’ll have to stop developing new features for six months to achieve it, is it worth it? Probably not.
Automated tests should give you confidence that the code works as expected. If you are already confident that your existing code works then there might be limited value in writing a suite of tests to prove it.
Try starting with tests to cover new features that you develop or bug fixes. With these cases you’ve got some code that you aren’t confident works as expected – or that you know doesn’t. Take the opportunity to document and prove the expected behaviour with some tests. Over time you’ll build a valuable suite of tests that you can run to demonstrate that each new release of your product works and that bugs haven’t been reintroduced.
With some practice you’ll find that you can use the library codeunits to create scenarios with little test code e.g. you can create a customer, item and sales order, post it and get the posted sales invoice in 2 lines of code.
Interested? More here…
James Pearson 
Well… I used to say that there needs to be an age restriction for writing tests: at least 10 years of experience. This sorts out most of the nonsense.
LikeLike
Wow…wasn’t expecting that. Thanks for the comment.
What kind of nonsense did that solve? Looking round our dev office we wouldn’t have too many people left to write tests if we enforced that 😉
LikeLike
Considering TDD as a preferred method of design, for example. You know, „make your tests green“ and that sort of thing. All you really do with that is create nonsense overhead, which doesn‘t really test anything. Good tests aim for the complexity of the implementation. This requires deep understanding on what to expect in the first place. Also, the idea to automate away end user testing of GUI is… interesting. It simply doesn‘t work that way, it only gives the appearance of some green lights on a dashboard. If you want to see some useful testing, I‘d recommend having a look at the git test suite.
LikeLike
I mostly agree:
– automated testing doesn’t replace manual testing
– defining what to tests and the expected results can be tricky, but is one of the most useful disciplines of the process – no reason consultants can’t help developers with this
– whether to follow TDD is a separate decision to whether you should write tests – BC is getting easier and faster to test from VS Code but following TDD strictly is still cumbersome
LikeLike
I can see I have managed to be totally misunderstood, so this is the view I was trying to express at keynote:
We were discussing the lack of resources that most partners is struggling with these days and I was pointing out that with the added complexity it might be useful, even for a small company, to start specializing your development team, and hire in new resources in the areas that are new to your traditional NAV/BC developers.
In many cases we see the developers with years of experience in the data model and business logic being unproductive, because they are now forced to struggle with all the new disciplines – and that’s a waste of talent and expensive resources.
You don’t need to understand the logic behind CU80 to master CI/CD, Dockers, PowerShell etc. so just hire in new, young people for this…. and make sure the “old dinosaurs” (yep that’s me) goes back to designing creative solutions that bring value to the customers.
That being said, I totally agree with your view on automated testing – it is something we (even the old dinosaurs) have to start including in our creation of new functionality, whereas our old legacy code being “tested” daily by thousands of users is not on top of my to-do list.
LikeLike
Hi Kasper,
Thanks for adding your clarification, good to hear from you 🙂
I’d only reiterate that if we don’t see enough value in following some new discipline then we shouldn’t do it. But if we are convinced of the value of say, isolated development with local Docker containers, then we need to explain the benefits and support those who struggle to pick it up – which isn’t necessarily just the old hands.
LikeLike
Thank you for share. A personal thoughts about this very interesting question:
First one is customization vs Repeatable code. For Customization most of times Test code is a waste of time, but for repeatable code and product is mandatory.
Doing test code doesn´t mean TDD: you can write good test code after writing code.
Using test units not the same making test code. You can pass standard NAV/BC test Codeunits to check if everything works OK after your modifications. I did this with my product and I got great improvements.
More thoughts about this question in https://community.dynamics.com/nav/b/conceptsindailynavisionwork/posts/test-code-beyond-tdd-part-1-of-3
LikeLike