Blog about software development
Using mocks and behavior testing is a great idea. Especially when you are dealing with complicated dependencies and business logic. But some people tend to use it also for very simple scenarios like CRUD operations. In my opinion even for middle sized projects there is no need to have more than 10% of behavior mocking tests. Typical business scenario that I am talking about can be following:
Mocking approach would introduce something like repository pattern. Than inject repository mock to the service and stub query and expect appropriate save. This will bring a lot of unnecessary abstraction to the code like repository interfaces. In the end the test will actually test only that the repository is invoked. I know there is usually a persistent test verifying that entity is correctly mapped to the database, but this is usually not enough. There are many pitfalls when you are using some sophisticated ORM framework that will just not be covered with persistence test and repository behavioral testing. I have seen many times situation where thousands of mocking tests where green and application was not even successfully starting.
Therefor my proposal is to rather test results and use mocks and behavior testing only when it’s necessary. Ideal way for testing previous scenario would be than just insert necessary entities to database, let the testing method do its job and verify database state afterwards.
I will try to give you some tips and examples for writing readable interacting tests in the next two posts.
Quite some time ago I blogged about rendering pdf reports in c#. Recently we have added excel reports into jsreport and it was released with a little delay also into .NET. This means you should be able to use both html-to-xlsx and xlsx recipes to create excel files from your .NET environments now.
Such a very common thing like adding an existing external volume to Amazon elastic beanstalk is not easily supported out of the box. The official blog mentions only how to attach a snapshot or how to attach and overwrite a new volume every time the service starts. It took me a while to make the config file actually adding an existing volume without formatting it every time so I share it here with you...
The best practice when adding email notifications feature to your system is to separate as much as you can from email body assembling to email sending outside of the core system. The emails templates quite likely often changes and you don't want to deploy the system because of every single notification change. The best is to just separate everything into an external system and give the access to your PR or Marketing department so they change emails as the time goes without affecting the core system.