Unit Testing is the modern slavery. You're controlled by a test. How you solve problem controlled by a fucking test. Your brain focus more on Test than actual problem. NASA who invented Unit Testing never succeeded, Russia that never followed any kind of this has successfully built Rocket Engines!

  • 12
    In mother russia you don't perform unit testing, unit testing performs you.
  • 8
    Either the program execute or we will execute you.
  • 4
    Sure thing, but on one side, you try to solve the possible problems preemptively, while on the other you just throw things (e.g. human lives) until it's solved.
  • 1
    I don't do unit tests because I think they're not worth the time spent on them, and they make refactoring a huge effort so that it will never happen because it's too expensive, i.e. they contribute to architecture rot.
  • 1
    Russia: "Trust me, i'm an engineer"

  • 4
    If your definition of slavery is planning before acting and then acting according to the plan, then sure, unit testing is just as bad as calling your primary branch "master".
  • 5
    @Fast-Nop then you are probably not testing right.
  • 13
    Unit tests, if done right is very good for quality.

    Yes, its more code to write and yes as @Fast-Nop writes, it can mean more work when refactoring.

    But it can also mean that you CAN refactor an old piece of code without being to afraid to break everything.

    Whats important is that each set of tests should only test one class or one integration so is easy to amend the tests if you need to change the class.

    And you should test business rules, not language features.

    Also, you should test for error conditions, does this throw if given bad input.

    If it suddenly does not, that could mean you have a possible security hole.

    Writing good unit tests is a skill you have to learn and train.

    But I have found had very much use if them.

    Also, they are more important in a code base that is big and do not change all the time.

    If you r code is not bigger than that you can refactor it all in a few weeks, you might end up spending a lot of time on the tests.
  • 2
    @Voxera I focus is on integration testing, which is requirement based. Another issue is that there must be no code that isn't backed up by a requirement.

    And no, you can't retest because refactoring means that you break that stuff, and since the amount of unit test code can easily dwarf the actual code, this is work that simply won't get done at all in the real world.

    It has no tangible benefit to the customer, therefore he won't pay for it. Neither can you hide it in the general project effort because then you'll be so expensive that customers will look elsewhere.
  • 4
    @Fast-Nop More complex projects have so many moving parts and possible inputs that actually testing all possible scenarios would need thousands of integration tests. In the project I'm currently working on we have a module that is complex enough to produce a few hundred integration tests, probably. It's nicely split into components though which have well-defined responsibilities and thanks to that we know what behaviors they should exhibit - and we unit test for them. There's about 150-200 unit tests I think and maybe two dozen integration tests. Yes, refactoring it would take a while, but it's already designed to be extensible and easy to modify so it's not like we would be changing half of its codebase along with unit tests. Usually you just have to glance at test names for the unit you're changing and you know which ones will need to be updated. Units usually don't change their responsibility, so removing/adding tests is rare.
  • 1
    Unit tests (done properly) encourage the writing of easily testable code, which in turn encourages code that follows solid principles, which in turn gives code that is easier to maintain.

    In other words, exactly as @gronostaj describes.
  • 1
    Modern slavery is the modern slavery.
  • 0
    @Fast-Nop integration testing is important, but in our solution consisting of around 50 projects with a couple of hundred to a few thousand code classes each (not counting pure data classes)

    Integration testing everything would take years to cover all combinations of edge cases.

    Unit tests ensure that every class follows its own requirements so that other classes can depend on that.

    And sure, some tests need to be rewritten from time to time, but its rarely that tests make up a significant part of new commits.

    But maybe we have different targets, I work on projects that we keep maintaining for 10+ years, not something we build and then deliver without having to worry about 5 years from now.
  • 0
    @Voxera I've had to update a project from 10 years ago this year, so that's there. I'm still not convinced of unit tests. Too much of a time sink for too little return.
  • 0
    @Fast-Nop one question, how many devs in the project, we are around 20 now and it used to be a bit more.
  • 1
    @Voxera Depends on what you're asking since coding is only a small part of the development over here. In terms of pure coders at the same time, that's about 2. Different coders across the whole project lifespan, dunno, but more than 10.

    I mean, it's not like I doubt unit tests can be useful. It's just that I doubt they deliver enough bang for the buck. And that doesn't change with more devs. It's just more devs wasting their time.

    If cost is not an issue for you, or if you're making stuff like nuclear reactors where the cost of bugs is essentially unbounded, that's a different story.

    Another point is that tests designed and performed by the coder are of very limited use anyway because the same misunderstandings when coding are then also covered in the tests.

    I think unit tests are a fad.
  • 1

    > the same misunderstandings when coding are then also covered in the tests.

    Tests aren't supposed to test if your code matches client's expectations. They're for testing if your code does what you intended. Properly written test suite is significantly simpler than the code under test and it's expressing your intentions case by case rather than solutions you came up with, so it's more likely to uncover mistakes than hide them. This applies to all kinds of tests.
  • 0
    @gronostaj But misunderstandings are the main source of bugs I encounter. Plus that mocking up everything is not only a huge amount of code, it's also tightly coupled to the implementation. With the consequence that refactoring becomes prohibitively expensive and therefore won't be done.
  • 2
    That's what I'm talking about. My unit tests are closer to e2e tests most of the time. They represent actual usage of the application and focus on practical exercise of the functionality.
  • 2
    @SortOfTested Yeah that's what I'd call integration tests, and they are not aware of the implementation. Which makes them useful even in refactoring because the same functionality should be there afterwards.
  • 2
    @gronostaj exactly. And therein you find much of the problem with many unit tests, what should you test.

    For example, its one thing to test that the code works with correct data, but good unit test should also test any case of bad data, like negative or ridiculously high numbers, or non existing keys or nulls where you do not expect a null (unless you use some language that prevents that)

    That edge cases works as expected.

    Its usually not so that unit tests cover all code, even if that is desired, but you most often start in some error prone part of the project where random bugs often appear.

    Unless you do TDD in which case everything should start with a test.

    But even TDD does not cost so much time since test, done right, usually takes very little time to write.

    Often you can reuse much of the setup for the test since each test only should test one aspect to be helpful.

    But I know I took a long time to really appreciate them.
  • 0
    @unclesam "How you solve problem controlled by a fucking test"
    @Fast-Nop "Yeah that's what I'd call integration tests, and they are not aware of the implementation"

    Unit tests do not control how you solve a problem and are not aware of the implementation. That would be rather silly, because you could never refactor your code (= change the implementation) without the tests breaking - which is the entire point of them existing: Ensuring your code exhibits certain characteristics regardless of internals.

    The distinction between unit, integration and system tests is mainly that of scope. You're applying the same principles with all of them.
  • 0
    @VaderNT Refactoring doesn't mean changing the implementation. Refactoring means e.g. shifting over functionality from classes A and B into C, and of course this breaks unit tests because you need to mock up different objects.
  • 1
    @Fast-Nop I disagree, changing the implementation is one possible form of refactoring. However, in the end it doesn't matter what you call it. If you cement the implementation with tests, you're making too many assumptions about internals.
  • 1
    @VaderNT exactly :)
    Unit test should ensure the interface of a function, not how it is achieved.

    And if you move functionality around you usually can move the tests pretty easily.

    If not, then the class most likely was to complex to begin with.

    But its not a necessity of cause.

    If one really do not want to use unit tests you probably should avoid them as you would most likely do a bad job with them :)
Add Comment