How Do You Test Your Software

attempting it in the fashion of TDD, will merely make it a maintenance nightmare and impossible for the team maintain.

You can't win that argument. They're making this up. Sadly, you have no real facts, either. Any example you provide can be disputed.

The only way to make this point is to have code which is lower cost to maintain.

Furthermore, as it's a front-end application (not web-based), adding tests is pointless,

Everyone says this. It may be partially true, also. If the application is reasonably well designed, the front-end does very little.

If the application is poorly designed, however, the front-end does too much and is difficult to test. This is a design problem, not a testing problem.

as the business drive changes (by changes they mean improvements of course), the tests will become out of date, other developers who come on to the project in the future will not maintain them and become more of a burden for them to fix etc.

This is the same argument as above.

You can't win the argument. So don't argue.

"I am fully responsible for the rewrite of this product"

In that case,

1. Add tests anyway. But add tests as you go, incrementally. Don't spend a long time getting tests written first. Convert a little. Test a little. Convert a little more. Test a little more.

2. Use those tests until someone figures out that testing is working and asks why things go so well.

I had the same argument on a rewrite (from C++ to Java) and I simply used the tests even though they told me not to.

I was developing very quickly. I asked for concrete examples of correct results, which they sent in spreadsheets. I turned the spreadsheets into unittest.TestCase (without telling them) and uses these to test.

When were in user acceptance testing -- and mistakes were found -- I just asked for the spreadsheets with the examples to be reviewed, corrected and expanded to cover the problems found during acceptance test. I turned the corrected spreadsheets into unittest.TestCase (without telling them) and uses these to test.

No one needs to know in detail why you are successful.

Just be successful.

Since I got addicted to unit tests more than 10 years ago, in the majority of my workplaces I was the first who has ever heard about these. Nevertheless I kept writing my little unit tests whenever I could, and estimating the cost of unit testing into my tasks. Whenever someone asked about my coding habits, I told what I was doing and why it worked for me. Usually at least some of the people were interested, and eventually I got to give presentations on the topic and mentored people to write their first unit tests.

You don't need to start convincing people about the agile way the first day at your new workplace. Just follow the principles in your own work as much as you can. If you do it well, you will deliver better code. If your coworkers and/or management notice it, they will ask how you do it. Then you can tell them.

Update

Most of the seasoned developers (and managers) have seen trends and fads come and go, so they do not get excited by the latest buzzwords. However, if you can demonstrate that a certain approach (tool, way of thinking) really works in practice, in the actual project, the ones who care about their craft will almost surely sit up and listen. But if you have no such people in your team, maybe it is time to look for a better place...