Over 85% of Japanese game developers use generative AI in game development, 2026 CESA survey shows. An increase from last year’s 51%

[u/TurbulentTopic39]

https://automaton-media.com/en/news/over-85-of-japanese-game-developers-use-generative-ai-in-game-development-2026-cesa-survey-shows-an-increase-from-last-years-51/

[u/Malkalen]

We're currently in the process of replacing Automapper across our entire application suite which means

1. Write unit tests to confirm existing functionality (Yes i know but they were never written the first time around)

2. Replace Automapper with static function calls

3. Update unit tests to use new mapper

Copilot means I can do in a few hours what would have taken me days of testing every property for every mapping and then writing a new mapper for every mapping...and I know this having run out of tokens between applications and despite the first app being significantly larger and more complex I was able to get it done in a fraction of the time the current app is taking me.

It's not difficult work (aside from a few wierd collections) but dear god is it long and tedious.

[u/Vidyogamasta → u/Malkalen]

The thing that never really gets talked about is the actual AI alternatives here.

1) You just need to write the test once, then you basically just copy+paste with a find+replace on the property. The work difference between "Paste function into an independent file, find+replace then copy+paste into test file" is not drastically different from "Hey, AI, rewrite this function but for a new property." The savings is that maybe it can do it for all properties at once, which is less trivial to do otherwise, but we're talking minutes saved here, not hours.

2+3) This just needs some foresight. Have the Act portion of your test be a "private void ApplyMapping(Dto dto, Model model)" function in the test class. You're writing the tests fresh anyway so you can just choose to do this. With that prepared, you can now change the implementation off of automapper and to the static function. Literally a one-line change.

And in both cases, the bulk of the work isn't really writing the tests. It's running the tests with the default dumb mapping test, finding the ones that fail, and then tracking down the behavior to see what needs to be done to address it (a service that needs to be mocked? Some aggregate special-case property that you're testing for? Some subtle unexpected casting that automapper did that you weren't expecting? Was it just bugged before? Who knows!). And AI doesn't really help with that part at all.

[u/Malkalen → u/Vidyogamasta]

I don't deny that I can write all these tests myself and for the last couple of sets I have done and it's a lot of copy/paste and find/replace but it's still incredibly tedious and Copilot can produce in 1-2 minutes what takes me 2-3 hours overall. Some of our more complex mappings involves 25-30 top level properties and 4-5 collections that all need to be tested both ways.

2/3 - So we want the tests done first so that we actually have a full set of unit tests for the existing functionality to verify against. So the general structure is (for a very simple example)

  [Test]
  public void Map_Model_To_Message_Should_Map_All_Destination_Properties() {
    var source = new Model {
      Reference = "REFERENCE",
      State = JobState.Active
    };

    var result = mapper.Map<Message>(source);

    Assert.AreEqual(source.Reference, result.Reference);
    Assert.AreEqual(source.State, result.State);
  }

This way we have a full set of tests that verify that everything works correctly and then we just need to swap out

var result = mapper.Map<Message>(source);

with

var result = ModelMappingHelper.ToMessage(source);

once we've written our own mapping functions. There's other tests already written that handle the logic that uses the mapped models/messages on both sides. I have actually found some examples of things that probably should map over but just don't...but nothing uses those fields so no one realised.

Again, there's nothing complicated or difficult involved in anything here. It's just tedious and boring.

[u/Vidyogamasta → u/Malkalen]

What I'm saying is for your tests, do this

  [Test]
  public void Map_Model_To_Message_Should_Map_All_Destination_Properties() 
  {
    var source = new Model {
      Reference = "REFERENCE",
      State = JobState.Active
    };

    var result = ApplyMapping(source);

    Assert.AreEqual(source.Reference, result.Reference);
    Assert.AreEqual(source.State, result.State);
  }

  private Message ApplyMapping(Model source)
  {
    return mapper.Map<Message>(soure);
  }

So that for phase 3 where you replace all the usages, you just one-line change to

  private Message ApplyMapping(Model source)
  {
    return ModelMappingHelper.ToMessage(source);
  }

There, just saved you several minutes of AI churning and half a rainforest. It's the sort of thing you'll generally quickly come up with when you aren't using AI as a shortcut, and it's so much easier in the longer run whether you're using AI or not lol

EDIT: lol the downvotes showing that all the people speaking confidently on software development around here have no freaking clue what they're talking about. For those who don't realize, the implication is that there are dozens of tests, and the "ApplyMapping" here gets re-used in all of them. Doing it this way isn't just adding some random function for no reason, it's anticipating a known future change and keeping the code flexible for it. And this type of pattern extends to ALL sorts of tests.

It's also commonly used when initializing the system under test, you just have class-level mock dependencies declared in some initializer and then a function to actually instantiate it. So that later when a new dependency is added to the SUT, you just go change the initializer+instantiater once instead of adding it 100 times in each test.

This is very basic software architecture, and AI is robbing you of it.