should e2e be concerned about the binary.

like in my rust i am not running the binary and passing arguments to that.

i am saying if my codes integrity is an i am concerned about. i am relying heavily on that fact that compiler will never produce the wrong binary.

i am not testing compiler here only my cute. if it produces correct code for my tests including subsets. it should do the same for the overall binary.

some places i can understand, flashing can go wrong. that’s why checks have to be performed.

but here checks that compiler can go wrong. i don’t know. it’s compilers responsibility right?

again, one question that rises from this is, fine no deployment test but you have to test your dockerfile right. that container image.

again. i would say isn’t a health check more than enough for this.

idk.

edit, 6:45pm imo ping test is more enough as a e2e test for a system.

cause each individuals are already treated

and you can’t test each individual path flow.

that’s the first reason we decoupled them to facilitate the tests.

easy separation of use cases. which are digestible.

for these systems. like linux os. it’s like are these guys able to call the different libs.

no, all that is fine. but are you able to invoke the build library that’s the thing.

again. should library be concerned with it? if someone is able to invoke.

but this is what testing in production is right?

yeah, as it autotyped, “great.” that’s the thing.

it’s testing, qa whatever you call. not tdd. not e2e.(tdd) not acceptance tests(tdd)

they are testing, quality assurance… and all that. that everything worked out good for this…

like load test and all, this is testing, i would even say this should be testing in production.

it’s not tdds concern…

i would like to call them deployment tests. they don’t test much, but build is correct. able to open it, ask it to do somethings, they are not extensive by any means.

like a lib test is just if i am able to link it, statically or dynamically and able to calls its subroutine. even one will suffice.

that extern thing, it should be part of e2e test. e2e test should test if extern is added. thats e2es job.

deployment is just simple health check. like hash check one can say.

same for k8s deployment or anywhere as such. just a simple ping check, health check. simple probe and its able to load and reply back, other services are able to find it. thats all.

now lets say, theres is a bug and it shouldn’t appear next time. first of all is that a compiler bug? we can’t do much. it should be compilers responsibility. if its our bug. why it happened. 5 whys. reproduce in tests of appropriate level. e2e or it or unit. and then only fix it. so to make sure it never happens again.

next day, making keydb. i don’t understand the concept of running tests after building… wtf is that shit… its wrong way of doing stuff. testing after implementation. i don’t like it. anyways again this is testing and not tdd…

fine… benchmark tests and all that stuff is also there. idk…

ok now i understand why these are they. but tbh, imo, they should have been builds part itself. but fine. make worked, but when trying to run, its unable to find a f8cking library. so its not even launching.

idk. thats the issue in linux work. library issues. other day he was saying the same. cause library got updated it stopped working.

but thats the thing. thats why docker exists. we will ship your system. prev. jvm, java was doing that. giving a stable interface to code against. thats why popular, enterprise.

now its docker…

but again, thats a issue. even with these tests you can’t

sidd, just understand tests have multiple meaning. its not always tdd. it means different stuff in different contexts.

anyways, fine, i will use docker…

on firmware side it makes sense. to have hardware tests. if its working properly after the flashing and all.

but thats the thing. thats where the difference come. se is different. its difference than this. those are abstractions, hardware is already tested. and shipped. and thats the thing. hardware testing is one time thing. its not going to change that often. the feedback loop is longer. it takes decades and all.

but here. thats the abstractions. thats the thing. these two are different things…

17 march 2023. ok, one more thing. its ever evolving. theres a bug. and we didn’t caught it. cause e2e scope was less. so, once we know that, we can migrate our e2e to that scope. make e2es scope wider. like in this sudoku. i am just e2e testing runEntry point. not actually invoking the binary and all.

thats fine for now. but lets

so again its evolving. and we are ready to take first bullet. but not the second time. so we reproduce that bug, issue and fix it. main thing is. do the bare miminum to make it work. and thats what i am trying to do here… doing the bare minimum…

i agree, e2es scope should not be that big also. thats why microservices.

but we also need another “tests” to verify that behavior, “if” there is a bug and we can only reproduce it in wider scope. and not in uts, its, and e2e. but there also do that bare minimum…

so if i see e2es scope won’t be expanded. but a minimum set of tests can be written so that that issues does not rise again, in bigger scope… anyways as i said its part of qa in big applications. testing in production and all that…

thats a different thing and feedback loop doesn’t matter there.

but with e2e it does. so it can’t be too big scope… its trying to boot up plethora of services to just test this guy. doesn’t make sense… i think so… :)