It depends on your application. If you write a converter and you have a series of fixed input sets you could convert those and report any differences with a prior conversion output. This is a valuable test. If your work is for one client at a time (your project is for one set of input data), that could work.
But then, although an alternative, it would not provide the same information as unit tests. It would just be a limited regression test.
- code coverage would be unknown;
- the test cycle would likely be longer, doing a full run on
your test data will be time consuming and also make developers
reluctant to do it after each change;
- the reference output may have errors from the beginning, you will never be sure.
In the end it is a matter of perception. Do you still see making tests as a cumbersome after-overhead task that the environment expects from you but you would rather skip so you can move ahead, or do you accept and embrace writing fitting tests as part of the development work and of your personal definition of done?
Apparently your developers feel the pressure to cut some corners. Or writing tests is just boring work to them. Perhaps they do not get "points" for them.
Is there a need to be strict on writing unit tests? Do you see a lot of bugs coming back that would have been caught by proper unit tests?
To some applications unit tests are invaluable. To others they may be no more than a pacifier. If you have clear fine-grained requirements you can hardly go wrong with them. If you only have one big requirement and you have to figure out all the small steps yourself, unit tests will not do much for you. They will merely affirm that your little trial does what you had in mind, not if it brings you any closer to your goal.
So as always, it depends. Think hard about what matters to your project, what makes sense to test and test that. The bugs you see may be an indicator.