|
>>
|
No. 2283
[Edit]
>>2280
>The CI-aspect (as opposed to simple unit-testing)
In my mind "continuous integration" is more about the infrastructure and is orthogonal to the issue of system/unit level tests. For instance, you could just have your CI scripts run all unit tests upon a commit. Unless your job deals with setting up such infrastructure, I don't think end-engineers ever have to explictly think about CI itself, since it's merely an automated mechanism that runs the tests.
> something that's expected from graduates of CS
(I haven't spent enough time in the industry to say for sure so take the below viewpoint with a grain of salt)
Considering that most university graduates barely have experience writing good unit tests, I doubt that new hires are expected to be able to think about system-level tests at all. In particular, while you can assume that graduates will at least have some basic exposure to the idea of unit tests (perhaps they might have had to write some themselves for an assignment, and they'd certainly be familiar with testing algorithms for correctness given the prevalent use of autograders), system level testing is something that very few students will have needed to think about given that in university, projects are usually small and simple enough that there's no need for this. It's only when you dive into things that have to deal with networking, databases, RPCs, etc. that the limitations of unit tests begin to show and it becomes worthwile to consider bringing up an entire sandboxed environment. (Somewhere in between that continuum of unit tests to entire sandboxed instances, there's the in-betweens of in-memory simulations, RPC replay, and perhaps even more that I'm not aware of).
|