Hacker News Reader

> test and integration tests are (bad) substitutes for good and modular design, which should piggyback on a strong type system

This sounds completely hand wavy. If the design is in fact modular and built of autonomous components then it should be relatively easy to test and should be tested. Types are no substitute for testing and are completely orthogonal to testing.

> Test code is brittle code

If this is the case then the code being tested is more than likely brittle as well. Test code reflects the system under test more than anything else.

> You need tests because you're using a dynamically typed language

No you simply need tests in any language.

> Types are no substitute for testing.

I don't agree with the person you're replying to that types make tests redundant, but to claim that types can't substitute a large amount of testing can only come from inexperience.

Whatever property you can model successfully through a closed type, is a property you never have to test ever again anywhere it's being used. If you have 500 functions that take a NonEmptyString, those are 499 fewer property checks in tests (because you should have one test for the type constructor).

> types can't substitute a large amount of testing can only come from inexperience

That is a very bold assertion I have seen no evidence for. I write very few tests in Ruby or Javascript aimed at validating types.

> You need tests because you're using a dynamically typed language?

I don't really understand the connection between a dynamically typed language and the need for (or lack of) testing. Can you explain what you mean? I've never once felt like the type of language I used defined how important tests were.

When I write a unit tests, I'm not looking for syntax errors or a scenario where I'm passing the wrong type in, I'm verifying that the business rules of my domain are being properly enforced.

If your unit test is brittle, I'd say that's a pretty awful unit test. You should be isolating the component you're testing and eliminating all external dependencies like in the example below.

    class ItemRecommenderGuardTest extends TestCase
    {
        public function setUp()
        {
           $dependency = Phake::mock(Dependency::class);
           $this->recommenderGuard = new ItemRecommenderGuard(
             $dependency
           );
        }

        public function testGuardsInvalidItem()
        {
          // business rules deem this item un-recommendable. This unit
          // test verifies that the guard class properly enforces these rules
          $item = /* ... */;

          $this->assertFalse($this->recommenderGuard->isRecommendable($item);
          
        }
    }

This test isn't brittle, and it's asserting that an item which does not meet recommendable standards is never recommendable. If someone comes along and modifies the guard class incorrectly, these unit tests are here to maintain the integrity of the system

To someone else that has programmed for a good 2 decades or more, the above sounds like cowboy programming that leads to unmaintainable systems.

Unit and integration tests are not "substitutes" for good and modular design. Good and modular design work hand in hand with tests to produce reliable, well understood, and maintainable code. The most testable code is usually often the most well separated code.

A strong type system provides the third leg of the tripod. It's not replaced by or a replacement for either of the other two.

Stop thinking that you're too good for test code. Your future senior dev self will thank you.

If you don't have tests for everything, how do you check that everything's still working fine? Because the only alternative I see to not thoroughly test code is to check the app by hand to make sure nothing's broken, which is, well... Not as robust as having it checked by a machine.

I think the idea isn't that you don't thoroughly test, but that types are sufficient tests of certain functionality, and they're significantly more expressive and efficient than their runtime equivalents.

A "good and modular design" with a "strong type system" won't help you when one of your dependencies has an upgrade with a subtle bug that changes the behaviour of your system.

> Unit test and integration tests are (bad) substitutes for good and modular design...

That's a complete non-sequitur. You can have spaghetti code that produces a correct result, and you can have a beautiful architecture that produces an incorrect result.

Testing is the only way to verify whether or not your code is producing the correct result. You can test by hand or automatically, but the ultimate determination on the correctness of the code relies on a test.

It has nothing to do with design.

Testing is a superset of type checking.

And people forget the main thing about TDD: The main goal is to validate your design

You don't get that with type systems.