home.social

#integrationtests — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #integrationtests, aggregated by home.social.

fetched live
  1. Engineering manager: I want #integrationtests to run on the app deployed on #Cloud infra for each #GitHub PR ✅

    Me, thinking it's a no-brainer: sure thing! 🤦‍♂️

    Me, after 85 runs: I have content for my next blog post/talk 😅

  2. Engineering manager: I want #integrationtests to run on the app deployed on #Cloud infra for each #GitHub PR ✅

    Me, thinking it's a no-brainer: sure thing! 🤦‍♂️

    Me, after 85 runs: I have content for my next blog post/talk 😅

  3. dev.to/slsbytheodo/blazing-fas - what if we could have multiple warm #cloud environments and "check-out" an environment for the #IntegrationTests? Then we don't need to start from scratch. We can evolve the environment for the #tests. Nice thought experiment linkedin.com/in/corentin-doue.

  4. dev.to/slsbytheodo/blazing-fas - what if we could have multiple warm #cloud environments and "check-out" an environment for the #IntegrationTests? Then we don't need to start from scratch. We can evolve the environment for the #tests. Nice thought experiment linkedin.com/in/corentin-doue.

  5. How do golang folks do integration tests for their apps?
    I am not sure writing loads of shell scripts is the best approach
    #golang #integrationTests

  6. How do golang folks do integration tests for their apps?
    I am not sure writing loads of shell scripts is the best approach
    #golang #integrationTests

  7. My team currently has #IntegrationTests that spin up the service under test and its database, inject some state, run a bunch of curl scripts to poke the APIs, and check the responses. Today it's a pile of bash code.

    What I'd like is a test framework that lets me easily:
    * run independent tests in parallel
    * start using Postman collections for the API calls
    * capture artifacts like log files and API responses after failing tests

    Any recommendations? Most places I've worked have either (a) written a bunch of custom framework code, or (b) bashed their favored unit test framework into a rough fit.

    There are a lot of solutions out there that look like (b) -- for example testcontainers. I've also gotten some suggestions to use a workflow platform like airflow and I'm worried that road leads to (a).

    Nobody inside Postman has admitted to any test framework integrations yet 🙂, though there are plenty of resources about using a Postman collection as a CI step.

    #ContinuousIntegration #SoftwareEngineering

  8. My team currently has #IntegrationTests that spin up the service under test and its database, inject some state, run a bunch of curl scripts to poke the APIs, and check the responses. Today it's a pile of bash code.

    What I'd like is a test framework that lets me easily:
    * run independent tests in parallel
    * start using Postman collections for the API calls
    * capture artifacts like log files and API responses after failing tests

    Any recommendations? Most places I've worked have either (a) written a bunch of custom framework code, or (b) bashed their favored unit test framework into a rough fit.

    There are a lot of solutions out there that look like (b) -- for example testcontainers. I've also gotten some suggestions to use a workflow platform like airflow and I'm worried that road leads to (a).

    Nobody inside Postman has admitted to any test framework integrations yet 🙂, though there are plenty of resources about using a Postman collection as a CI step.

    #ContinuousIntegration #SoftwareEngineering

  9. If you code in OOP with the concept of SoC and SOLID you have the possibility to write modern modular classes.

    Take the focus on the testability of the code you write and it will show you the way which you can/must go.

    1. #unittest
    2. #functionaltests
    3. #integrationtests
    4. #apitests
    5. #acceptancetests

    From top to bottom
    From many to few tests

  10. Some thoughts triggered by martinfowler.com/articles/prog:

    - "product-mode company" is clearer than "tech company"
    - #Product vs #Project is a "pick your poison" issue
    - The largest risk to any program is probably integration
    - Anticipate #dependencies by studying historical #blockers.
    - #IntegrationTests and milestones are more trustworthy than status reports.
    - What is an effective virtual equivalent to a physical #ProgramWall? Honestly, I don't know.

    #ProgramManagement

  11. Some thoughts triggered by martinfowler.com/articles/prog:

    - "product-mode company" is clearer than "tech company"
    - #Product vs #Project is a "pick your poison" issue
    - The largest risk to any program is probably integration
    - Anticipate #dependencies by studying historical #blockers.
    - #IntegrationTests and milestones are more trustworthy than status reports.
    - What is an effective virtual equivalent to a physical #ProgramWall? Honestly, I don't know.

    #ProgramManagement

  12. Cursed CI setup in ongoing:

    - Flutter bundled into headless sway dockerimage
    - UNIX socket communication for CLI execution
    - VNC server for recording
    - still permission issues in volumes (easy to solve)

    #FluffyChat is close to getting #Linux #IntegrationTests !

    #matrix

  13. #FluffyChat is now given a proper #IntegrationTests setup via MR gitlab.com/famedly/fluffychat/.

    The changes include:
    - testing full features against all homeservers (#Synapse, #Conduit & #Dendrite)
    - normalize the app's behavior independent of platform (currently Android FLOSS, Android proprietary and Linux supported)
    - set of built-in helpers in order to simplify user login, logout or bootstrap processes in all future test cases

    Platform-specific workarounds just took around 30 h of work.

    #matrix

  14. If your #IntegrationTests fail, patch your dependencies so that your integration tests pass. #XML #Dart

  15. Atíla Neves ponders about
    #UnitTesting. The #D programming language is too closely coupled to #libclang, and Neves is working on separating it. In the process Neves found the unit tests to be #integrationTests rather than individual tests. Neves held many tech talks telling us to avoid that. So Neves feels ashamed, and will be correcting the tests.

    atilanevesoncode.wordpress.com