Rest is for the dead

Previously Baguette@lemm.ee

  • 0 Posts
  • 9 Comments
Joined 2 years ago
cake
Cake day: February 1st, 2024

help-circle


  • Baguette@lemmy.blahaj.zonetoFuck Cars@lemmy.worldTalk about mixed messages
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    2
    ·
    6 days ago

    Tokyo is not even close to being affordable? A 25m2 1bd is still roughly 1400 usd per month. You can get it down to 800 usd ish if you only want a small 15m2 studio. Those kinds don’t come with any kitchen and you only have a mini fridge. And that’s just the rent alone.

    Then you get hit with the tokyo salary which depending on the sector you work in could be 20 to 60 percent of a pay cut. The median salary is about 40k usd in Tokyo.

    Like sure there are benefits but Tokyo is not affordable, just look at the rise of adults in their 20s and 30s living with their parents in Japan, and even the rise of unemployed throughout asia (south korea and japan leading this metric)

    Edit: i forgot exponent sign is considered formatting



  • The issue with my org is the push to be ci/cd means 90% line and branch coverage, which ends up being you spend just as much time writing tests as actually developing the feature, which already is on an accelerated schedule because my org has made promises that end up becoming ridiculous deadlines, like a 2 month project becoming a 1 month deadline

    Mocking is easy, almost everything in my team’s codebase is designed to be mockable. The only stuff I can think of that isn’t mocked are usually just clocks, which you could mock but I actually like using fixed clocks for unit testing most of the time. But mocking is also tedious. Lots of mocks end up being:

    1. Change the test constant expected. Which usually ends up being almost the same input just with one changed field.
    2. Change the response answer from the mock
    3. Given the response, expect the result to be x or some exception y

    Chances are, if you wrote it you should already know what branches are there. It’s just translating that to actual unit tests that’s a pain. Branching logic should be easy to read as well. If I read a nested if statement chances are there’s something that can be redesigned better.

    I also think that 90% of actual testing should be done through integ tests. Unit tests to me helps to validate what you expect to happen, but expectations don’t necessarily equate to real dependencies and inputs. But that’s a preference, mostly because our design philosophy revolves around dependency injection.


  • To preface I don’t actually use ai for anything at my job, which might be a bad metric but my workflow is 10x slower if i even try using ai

    That said, I want AI to be able to do unit tests in the sense that I can write some starting ones, then it be able to infer what branches aren’t covered and help me fill the rest.

    Obviously it’s not smart enough, and honestly I highly doubt it will ever be because that’s the nature of llm, but my peeve with unit test is that testing branches usually entail just copying the exact same test but changing one field to be an invalid value, or a dependency to throw. It’s not hard, just tedious. Branching coverage is already enforced, so you should know when you forgot to test a case.

    Edit: my vision would be an interactive version rather than my company’s current, where it just generates whatever it wants instantly. I’d want something to prompt me saying this branch is not covered, and then tell me how it will try to cover it. It eliminates the tedious work but still lets the dev know what they’re doing.

    I also think you should treat ai code as a pull request and actually review what it writes. My coworkers that do use it don’t really proofread, so it ends up having some bad practices and code smells.