4 ms·

Say a bit more please

by bckr 5y ago

pjmlp 5y ago
Write a breaking test for that XAML element to look like Mica in Windows design language. Remember, no code without breaking test.
- berkes 5y ago
  It sounds like you are testing the wrong things on the wrong level. The test checking the correct color for a 'save button' in specific configuration, would most likely be a unit test for the "SaveButtonComponent" which simply checks that the correct attributes are set or passed on to a library. When you insist on having some coverage for the colors in the layer of e2e tests there are numerous tricks. Most of which you'd need to do only once and certainly not for every permutation of state. Like making a screenshot and diffing that with a fixture then failing on a too-big-delta. Or like running an accessbility-report over the app and failing if the values for things like "readability" drop below a threshold. And so on. You mention XAML, and I have little experience with windows GUI dev, but many setups, frameworks etc employ some adapter or layered architecture. Where the layer that drives the actual GUI library is but an adapter. So that the tests can swap out the actual GUI drawing layer for test-version theref, and do things like "confirmationModal.confirm()" without going through the entire UI. Or where tests can simply call a "confirmatioModal.buttons.map (b)=> b.colors.backGround" to get to the colors that are otherwise passed on to the actual GUI lib. This is why testing-pyramid is so important: to test on the correct level.
  - pjmlp 5y ago
    For application code to be written, regardless in what form and shape, a test must exist, so the TDD religion. You fail to adress that.
    - berkes 5y ago
      > You fail to adress that. I can write the `SaveButtonTest` before writing the `SaveButton`. I can write a `VisualComparisonTest.itKitchenSinkPageScreenshotMatchesFixture()` before having the KitchenSink view. I can write an AccessibilityReportThreshold.save_game_modal_meets_a11y_reqs() before having any application code to run the report on (it will fail with an error, which is expected and good). The fact that you condescendingly call it "TDD religion", however, tells me, I'm not going to convince of the value of tests at all, let alone the difference in value from the moment of writing the test.
      - AnimalMuppet 5y ago
        When I did TDD, we'd start by writing a test. The tests wouldn't compile (Java) or link (C++) because the function being tested didn't exist yet. Then we'd write the (empty) function. The test would fail, because the function didn't exist. (It's very important that you see the test fail! You need to know that the test actually can detect if the function doesn't work.) Then we'd implement the function, and re-run the test.
      - pjmlp 5y ago
        Unit and integration tests are valuable. The religion that every line of code needs a test before it gets written not so much, specially since many designs require human testing.

Say a bit more please

by bckr 5y ago

Say a bit more please

Write a breaking test for that XAML element to look like Mica in Windows design language. Remember, no code without breaking test.

berkes 5y ago
It sounds like you are testing the wrong things on the wrong level. The test checking the correct color for a 'save button' in specific configuration, would most likely be a unit test for the "SaveButtonComponent" which simply checks that the correct attributes are set or passed on to a library. When you insist on having some coverage for the colors in the layer of e2e tests there are numerous tricks. Most of which you'd need to do only once and certainly not for every permutation of state. Like making a screenshot and diffing that with a fixture then failing on a too-big-delta. Or like running an accessbility-report over the app and failing if the values for things like "readability" drop below a threshold. And so on. You mention XAML, and I have little experience with windows GUI dev, but many setups, frameworks etc employ some adapter or layered architecture. Where the layer that drives the actual GUI library is but an adapter. So that the tests can swap out the actual GUI drawing layer for test-version theref, and do things like "confirmationModal.confirm()" without going through the entire UI. Or where tests can simply call a "confirmatioModal.buttons.map (b)=> b.colors.backGround" to get to the colors that are otherwise passed on to the actual GUI lib. This is why testing-pyramid is so important: to test on the correct level.
- pjmlp 5y ago
  For application code to be written, regardless in what form and shape, a test must exist, so the TDD religion. You fail to adress that.
  - berkes 5y ago
    > You fail to adress that. I can write the `SaveButtonTest` before writing the `SaveButton`. I can write a `VisualComparisonTest.itKitchenSinkPageScreenshotMatchesFixture()` before having the KitchenSink view. I can write an AccessibilityReportThreshold.save_game_modal_meets_a11y_reqs() before having any application code to run the report on (it will fail with an error, which is expected and good). The fact that you condescendingly call it "TDD religion", however, tells me, I'm not going to convince of the value of tests at all, let alone the difference in value from the moment of writing the test.
    - AnimalMuppet 5y ago
      When I did TDD, we'd start by writing a test. The tests wouldn't compile (Java) or link (C++) because the function being tested didn't exist yet. Then we'd write the (empty) function. The test would fail, because the function didn't exist. (It's very important that you see the test fail! You need to know that the test actually can detect if the function doesn't work.) Then we'd implement the function, and re-run the test.
    - pjmlp 5y ago
      Unit and integration tests are valuable. The religion that every line of code needs a test before it gets written not so much, specially since many designs require human testing.