Whargharbl. Adding stuff to a services that has almost zero tests. So much guesswork about the input. Really hard to add my own tests as well what with the guesswork - I'd have to add tests all the way from top to bottom to assert stuff.
Turns out I get an endpoint that is just a hostname:port, no scheme. :rotate:
Does the service use dependency injection, i.e. do objects get passed in to the service's constructor instead of being created by the service? If so, that makes testing a lot easier because you can mock the input objects.
If it doesn't use dependency injection, good luck, testing will be almost impossible without refactoring.
Whargharbl. Adding stuff to a services that has almost zero tests. So much guesswork about the input. Really hard to add my own tests as well what with the guesswork - I'd have to add tests all the way from top to bottom to assert stuff.
Turns out I get an endpoint that is just a hostname:port, no scheme. :rotate:
Does the service use dependency injection, i.e. do objects get passed in to the service's constructor instead of being created by the service? If so, that makes testing a lot easier because you can mock the input objects.
If it doesn't use dependency injection, good luck, testing will be almost impossible without refactoring.
The bits I'm adding are properly mockable and used via injection, but I'm bolting that onto an old heap of weird factory functions.
Whargharbl. Adding stuff to a services that has almost zero tests. So much guesswork about the input. Really hard to add my own tests as well what with the guesswork - I'd have to add tests all the way from top to bottom to assert stuff.
Turns out I get an endpoint that is just a hostname:port, no scheme. :rotate:
Does the service use dependency injection, i.e. do objects get passed in to the service's constructor instead of being created by the service? If so, that makes testing a lot easier because you can mock the input objects.
If it doesn't use dependency injection, good luck, testing will be almost impossible without refactoring.
The bits I'm adding are properly mockable and used via injection, but I'm bolting that onto an old heap of weird factory functions.
If by solve you mean makes it slightly less ass but gets beaten on performance soundly still, sure.
I assume this because some time is spent waiting for each request/response cycle, and some is spent actually handling the responses, and http/2 won't help at all with the latter, so batching it all into one response is always better?
There is request overhead on top of the actual content payload, and the payload itself has overhead (metadata/compression on 1 image vs 100 images) so your actual network bytes is not magically reduced by using http/2. It just helps avoid handshaking/network protocol overhead, but it can't make optimizations across your payloads like sprite-sheeting can.
Sprite sheets make a special case with images, taking advantage of the fact that part of an image is still an image and if you want to do the coordination work on the client you can save a lot on the resource side.
A parallel to the HTTP request overhead is copying files. You run into very noticeable issues with file systems when you copy 10,000 files of 10kb each, versus one file that is simply a straight concatenation of all those files. HTTP/2 just removes the blocking serial aspect of most browsers (they parallelize it a bit with multiple connections, but not many, often only as much as two at a time). If you think about the file system equivalent, copying 10,000 files serially is really slow even though the amount of data you are writing is the same as the one file. And if you just say "write them all at once!" do you get to the speed of the one file copy? Heck no! Why? Resource implementation and overhead is still there. You're going to run into storage thrashing, having to write out a bunch of metadata in every place at once, storage systems can't write like that concurrently so it will get backed up into serial writes de facto anyways, etc. Writing 10,000 files of data will always be slower than just writing it all serially, and how close you can get depends on how many bottlenecks you can remove.
HTTP/2 removes zero bottlenecks on the resource side, it just throws everything at the server and removes the client side bottleneck.
So, I was chatting with another programmer and told him about how I bring C back from the dead like I do. He asked how on earth do you unit test C without an assert function. I told him I don't really do unit testing and he seemed aghast! Now, I only know unit testing is something like you write some program that just calls your functions to make sure you get the right results. Wouldn't that be more for, like, if you write a library or something?
Unit test = testing the basic units, in this case individual functions. Doesn't have to be every single function, I only test exported functions since they'll be using the unexported functions anyway. And some stuff is too trivial to bother testing.
So I have one set of unit tests for my database repository. Then I have mocks for that repository, and when I test something that uses the repository, say a REST API, I inject those mocks so I don't have to duplicate repository tests in the API tests.
...so yeah, it's about testing libraries/logical collections of functions.
On that note I like the httpmock package I use to test REST APIs. It hooks into Go's underlying http library and lets me control the responses, so I'm making actual HTTP calls in my tests.
+1
KakodaimonosCode fondlerHelping the 1% get richerRegistered Userregular
You can make a basic test framework in C with signals and signal handlers. Set up your signal handler and then raise a signal if the test fails.
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Steam: Spawnbroker
+2
OrcaAlso known as EspressosaurusWrexRegistered Userregular
I've found it's handy as hell for library code that is not dependent on external resources. Where it falls down/requires a shitload of work is when you're relying heavily on external resources that may not have suitable mocks and simulations available.
0
thatassemblyguyJanitor of Technical Debt.Registered Userregular
I've found it's handy as hell for library code that is not dependent on external resources. Where it falls down/requires a shitload of work is when you're relying heavily on external resources that may not have suitable mocks and simulations available.
opmock is reasonably functional for mocking C code dependencies. It has some rough edges, but usually once the setup work is done, adding tests is pretty easy.
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I've found it's handy as hell for library code that is not dependent on external resources. Where it falls down/requires a shitload of work is when you're relying heavily on external resources that may not have suitable mocks and simulations available.
opmock is reasonably functional for mocking C code dependencies. It has some rough edges, but usually once the setup work is done, adding tests is pretty easy.
The main problem I inevitably have is that the things I want to check are things like "did these changes screw up the control loop". Which means interactions between the code, RTL, analog hardware, and the physical device I'm manipulating. In the places where the firmware is running most of the show I can drop in a simple model of whatever it is I'm replicating; in places where the RTL is running the show that's...much more difficult without re-implementing the RTL as part of the test.
One dream is to someday have a full simulation of the entire chip (RTL + firmware + a basic analog model) that can run through startup of the system--it would probably take a couple days to complete but man it would be cool. :P
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Plz no. Do you know how much it hurts in intern season when you hear "I don't get unit testing, why bother?" Even worse if they never hear about it, because now it's "well I wasn't taught this in school, and obviously they'd teach it in school if it were important!"
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Plz no. Do you know how much it hurts in intern season when you hear "I don't get unit testing, why bother?" Even worse if they never hear about it, because now it's "well I wasn't taught this in school, and obviously they'd teach it in school if it were important!"
I don't know if this outlook is true, as pretty much nothing I learned in school was useful compared to what I have learned in the real world.
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Plz no. Do you know how much it hurts in intern season when you hear "I don't get unit testing, why bother?" Even worse if they never hear about it, because now it's "well I wasn't taught this in school, and obviously they'd teach it in school if it were important!"
I don't know if this outlook is true, as pretty much nothing I learned in school was useful compared to what I have learned in the real world.
Interns! INTERNS!
Though really, total agreement on school vs academia. I have the furthest thing from a tech degree, but apart from some theory, nothing would have been helpful in what I would have gotten. (And as I don't really care to do proper CS/architecture/design, the theory is less useful than otherwise.)
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Plz no. Do you know how much it hurts in intern season when you hear "I don't get unit testing, why bother?" Even worse if they never hear about it, because now it's "well I wasn't taught this in school, and obviously they'd teach it in school if it were important!"
The ones we "teach" unit testing aren't that much better. All they get of unit testing is in first year, there's maybe a week or so on it, they have to write unit tests for their assignments, and maybe there's a couple questions about it on the exam. And then it's promptly dropped and forgotten about for the next 3+ years, because we don't have the time to mark their unit tests, and they don't have time to make them.
Like, I think there's a whole big conversation to be had about what businesses want versus what universities can actually, effectively teach. Some things just don't square up well into 4-month terms, 2 week projects, midterms, and final exams. Like, teaching students how to work on big software projects: neato. Except running our 2nd term-long group project course is a huge pain in the ass, because students drop, students bail, and oh, on the side we're also trying to teach them Java, regex, UML, software design patterns, and version control all at once, and by the end of the project, they've written so much code that we don't have the TA time to review it all, never mind figure out how to mark it consistently, especially if we've been marking and giving them feedback throughout the term. Where the hell are we going to fit in unit testing?
I dunno. At this point in time, pretty much all my favourite undergraduate students have taken 5 (academic) years to graduate. Whether that's by taking an actual fifth year, or taking summer courses, or cramming in >5 courses in a term, or taking some remote courses while doing an internship. And these are my favourite undergraduate students, the ones with talent and potential that I keep tabs on after I teach them. At a certain point, I think the programming/CS community has to recognize that 4 years just isn't enough any more to teach grads everything they supposedly have to know, not unless we dramatically change how we teach it. I dunno how they're supposed to learn neural networks and deep learning in 4th year, when the first two/three years of the curriculum are basically still the same as they were when I did my undergrad 10+ years ago. As a community, we need to do a better job of figuring out what students actually need to learn in their 4 years, what can be delivered effectively, and how to deliver it.
(Sorry to get all existential up in your programming thread, y'all.)
You know what's funny.... I just ran across an issue where a unit test probably would of been helpful.
The issue was in my game. All the communications were garbled. Turns out that there is a random modifier added of your ships communication system is just out of range. It depends on the the rand() function... Which is different in Linux and Windows
Windows:
//! Return random int
/*!
\param x range from 0 to x-1
\return random number
*/
int Rnd(int x)
{
float t;
t = (float)rand() / 32768.0 * x;
return((int)t);
}
Linux:
int Rnd(int x)
{
float t;
t = rand() % x;
return((int)t);
}
It would of been nice to know that rand() works differently each platform....
Technically you should be using RAND_MAX there, not a number, then you can merge them
Though if you care about uniformity you shouldn't do divide by maximum multiply by n (this is especially bad if you are truncating, the maximum only occurs when you roll the maximum number exactly) or just mod by n. You would want to throw away numbers > RAND_MAX - RAND_MAX % n; you create n equal subsets, discard the unequal result range and hope you have a uniform RNG underneath
Unit testing seems like a lot of work for little effect to someone who has never used it before. What it does do, however, is lets you avoid entire classes of bugs that you never have to deal with again. You KNOW that this function is not outputting a null pointer, because you tested for that and the test just passed.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Plz no. Do you know how much it hurts in intern season when you hear "I don't get unit testing, why bother?" Even worse if they never hear about it, because now it's "well I wasn't taught this in school, and obviously they'd teach it in school if it were important!"
The ones we "teach" unit testing aren't that much better. All they get of unit testing is in first year, there's maybe a week or so on it, they have to write unit tests for their assignments, and maybe there's a couple questions about it on the exam. And then it's promptly dropped and forgotten about for the next 3+ years, because we don't have the time to mark their unit tests, and they don't have time to make them.
Like, I think there's a whole big conversation to be had about what businesses want versus what universities can actually, effectively teach. Some things just don't square up well into 4-month terms, 2 week projects, midterms, and final exams. Like, teaching students how to work on big software projects: neato. Except running our 2nd term-long group project course is a huge pain in the ass, because students drop, students bail, and oh, on the side we're also trying to teach them Java, regex, UML, software design patterns, and version control all at once, and by the end of the project, they've written so much code that we don't have the TA time to review it all, never mind figure out how to mark it consistently, especially if we've been marking and giving them feedback throughout the term. Where the hell are we going to fit in unit testing?
I dunno. At this point in time, pretty much all my favourite undergraduate students have taken 5 (academic) years to graduate. Whether that's by taking an actual fifth year, or taking summer courses, or cramming in >5 courses in a term, or taking some remote courses while doing an internship. And these are my favourite undergraduate students, the ones with talent and potential that I keep tabs on after I teach them. At a certain point, I think the programming/CS community has to recognize that 4 years just isn't enough any more to teach grads everything they supposedly have to know, not unless we dramatically change how we teach it. I dunno how they're supposed to learn neural networks and deep learning in 4th year, when the first two/three years of the curriculum are basically still the same as they were when I did my undergrad 10+ years ago. As a community, we need to do a better job of figuring out what students actually need to learn in their 4 years, what can be delivered effectively, and how to deliver it.
(Sorry to get all existential up in your programming thread, y'all.)
Honestly, I don't feel--and never have--that "CS" should be "the programming degree", or "the developer degree". What you learn has little to no vocational application, and hell, shouldn't. College isn't just "job preparation", and seriously, show me one software-related company that's anywhere near as sane as anything presented in a text. Why in hell is "version control" an academic topic, I mean? Best developer I've ever met (well, one of) is a former art major, after all.
This, however, is as well an existentialism.
Edit: And to @halkun yes, that is exactly why testing. "Did this thing I did actually do what I think I did, and did I break anything else I did?" Add time to the front end in test writing, etc, save EVER so much in "not trying to figure out why adding 2+2 is now equal to "cheese"."
I think the biggest problem is that CS isn't taught in any capacity prior to university-level education. All the other sciences have multiple years of background being taught at the middle school and highschool level. CS and other programming adjacent degrees are stuck teaching the ground-level basics in addition to the high level topics, and there just isn't enough time for that.
I think the biggest problem is that CS isn't taught in any capacity prior to university-level education. All the other sciences have multiple years of background being taught at the middle school and highschool level. CS and other programming adjacent degrees are stuck teaching the ground-level basics in addition to the high level topics, and there just isn't enough time for that.
This is one issue. Another is that "computer science" as a discipline has little to nothing to do with "being a developer" outside of very particular cases, and as an industry and profession, we're not doing ourselves any favors by conflating the two things. I mean it's like expecting your lab techs to have a degree in microbiology, or every single person working on your car to have a degree in mechanical engineering.
All that said, this is not me being in favor of the concept of "boot camps", because holy shit that industry is on the whole worse than for-profit online colleges... I just don't think "University" the way we're doing is the way to fix it.
I think the biggest problem is that CS isn't taught in any capacity prior to university-level education. All the other sciences have multiple years of background being taught at the middle school and highschool level. CS and other programming adjacent degrees are stuck teaching the ground-level basics in addition to the high level topics, and there just isn't enough time for that.
This is one issue. Another is that "computer science" as a discipline has little to nothing to do with "being a developer" outside of very particular cases, and as an industry and profession, we're not doing ourselves any favors by conflating the two things. I mean it's like expecting your lab techs to have a degree in microbiology, or every single person working on your car to have a degree in mechanical engineering.
All that said, this is not me being in favor of the concept of "boot camps", because holy shit that industry is on the whole worse than for-profit online colleges... I just don't think "University" the way we're doing is the way to fix it.
A lot of people recognize that there needs to be a split, but so far, the plan of having colleges take over professional developer training and universities handle academic computer scientist training has not worked. For various entirely obvious reasons.
For example, why do we teach our students code versioning systems? Because employers said they wanted our students to learn it, and our graduates said we should have taught them. So we do. We could say no, we won't, that's for programmers not for computer scientists - not really since researchers have to have repos for our code too - go hire someone from the local college if you want someone who knows code versioning, but they won't and we won't so we are where we are, via inertia generating a collective action problem.
I think the biggest problem is that CS isn't taught in any capacity prior to university-level education. All the other sciences have multiple years of background being taught at the middle school and highschool level. CS and other programming adjacent degrees are stuck teaching the ground-level basics in addition to the high level topics, and there just isn't enough time for that.
Yep. It's really... first-year CS is so completely different from most other first-year university courses. But there are all sorts of problems with high school CS programs, as they've been rolled out worldwide so far, such as not having $$$ for computers in many public systems, not being able to find CS people to teach for shitty high school salaries, lack of standardization and rigour in high school CS curricula, etc.. Most unis still operate as though there are no high school CS programs, because the high school students who have a significant CS background are so few and so inconsistent anyways, it's not worth revamping anything. Maybe they get to skip CS1 and go straight into CS2.
IMO the most pressing problem with the expectation of cs degree is research/theory focused and doesn't care about practicalities of industry and college for developers, is that I think the market for research focused people is small compared to industry so you need universities to be willing to drastically reduce or even cut programs or to adopt a strong competitive disadvantage for most of their undergraduates
And companies will still prefer someone with a good theory background for those 1% of times where a cs degree is actually really useful in a day-to-day job
IMO the most pressing problem with the expectation of cs degree is research/theory focused and doesn't care about practicalities of industry and college for developers, is that I think the market for research focused people is small compared to industry so you need universities to be willing to drastically reduce or even cut programs or to adopt a strong competitive disadvantage for most of their undergraduates
And companies will still prefer someone with a good theory background for those 1% of times where a cs degree is actually really useful in a day-to-day job
I wonder if this is changing though. As the tech industry booms and - I imagine - IT department growth has relatively stabilized - since all the large corporations already have their IT departments now - I wonder if the average nature of programmer work is beginning to change at all.
JacobyOHHHHH IT’S A SNAKECreature - SnakeRegistered Userregular
What if there was a software engineering degree that had some relevant computer science, but a bigger focus on the skills needed to build and maintain significant sized projects? That might be a better fit...
I mean, this isn't just an issue exclusive to the computer science domain. I received my degree in nuclear engineering and it's not like I learned everything I needed to hit the ground running in that field. You were just expected to pick things up on the business side and knew "Okay, 1 rem is too much exposure outside this container". All the degree meant was "Hey, this guy knows some about how nuclear reactors work and can learn things I guess?" Maybe we're expecting too much vocational from our universities.
Same thing for law. You learn the law in law school, but you learn that the local judge is an asshole in the school of hard knocks. (That's why I do web development these days: if my script is misbehaving it's my own fault, not because it violated its probation by making threatening phonecalls to its ex-wife. Plus I don't lose sleep at night for fear of being sued for malpractice! Yay!)
I think we need some sort of accreditation and apprentice system like engineers have, where you can't be called an engineer until you have a certain amount of real work experience and take the test to prove it.
Good luck convincing the industry to do that or have anyone decide on what's important, though.
The biggest problem with learning things on the job is that learning practicum on the job is almost always both incomplete and partially wrong, see for instance building an entire software architecture on SQL CLRs. So you need some theoretical knowledge as well in order to not be guided into a hole where SQL is the only hammer and every problem is a nail. But the problem with learning theory on the job is that you can't fucking do it.
At college I have the opportunity to spend hours every week studying these things. I get direct attention from an expert whose job is to teach me this stuff for hours every week. I have the opportunity each week to go get one-on-one time with that expert to answer specific questions. College and university have a whole big support system to ensure you can learn that stuff if you actually want to learn it.
I have to send eight emails to four different people to get ONE of them to sit with me for half an hour, and it takes weeks to set it up and that's the only time it happens, because everyone is constantly busy with their own stuff they need to get done. And that's assuming they don't hit a crunch in the next couple weeks and need to cancel. There are people I can meet with spontaneously but if they don't happen to have the knowledge I need, guess I'm sending out emails and praying.
Education should absolutely be providing as complete a theoretical framework to students as possible, which includes versioning, testing, debugging, etc, and essentially nothing except implementation details should be learned on the job.
Posts
Does the service use dependency injection, i.e. do objects get passed in to the service's constructor instead of being created by the service? If so, that makes testing a lot easier because you can mock the input objects.
If it doesn't use dependency injection, good luck, testing will be almost impossible without refactoring.
The bits I'm adding are properly mockable and used via injection, but I'm bolting that onto an old heap of weird factory functions.
Good luck soldier :hydra:
There is request overhead on top of the actual content payload, and the payload itself has overhead (metadata/compression on 1 image vs 100 images) so your actual network bytes is not magically reduced by using http/2. It just helps avoid handshaking/network protocol overhead, but it can't make optimizations across your payloads like sprite-sheeting can.
Sprite sheets make a special case with images, taking advantage of the fact that part of an image is still an image and if you want to do the coordination work on the client you can save a lot on the resource side.
A parallel to the HTTP request overhead is copying files. You run into very noticeable issues with file systems when you copy 10,000 files of 10kb each, versus one file that is simply a straight concatenation of all those files. HTTP/2 just removes the blocking serial aspect of most browsers (they parallelize it a bit with multiple connections, but not many, often only as much as two at a time). If you think about the file system equivalent, copying 10,000 files serially is really slow even though the amount of data you are writing is the same as the one file. And if you just say "write them all at once!" do you get to the speed of the one file copy? Heck no! Why? Resource implementation and overhead is still there. You're going to run into storage thrashing, having to write out a bunch of metadata in every place at once, storage systems can't write like that concurrently so it will get backed up into serial writes de facto anyways, etc. Writing 10,000 files of data will always be slower than just writing it all serially, and how close you can get depends on how many bottlenecks you can remove.
HTTP/2 removes zero bottlenecks on the resource side, it just throws everything at the server and removes the client side bottleneck.
So I have one set of unit tests for my database repository. Then I have mocks for that repository, and when I test something that uses the repository, say a REST API, I inject those mocks so I don't have to duplicate repository tests in the API tests.
...so yeah, it's about testing libraries/logical collections of functions.
On that note I like the httpmock package I use to test REST APIs. It hooks into Go's underlying http library and lets me control the responses, so I'm making actual HTTP calls in my tests.
opmock is reasonably functional for mocking C code dependencies. It has some rough edges, but usually once the setup work is done, adding tests is pretty easy.
Or that the function will do what you want if you pass in bad data, too. It's "easy" to make functions that do the right thing to sensible data, what I always forget is stuff like "does the code still work if the list of input has children before parents? what if this item's parent ID is somehow not in the list at all? what if A has B as parent and B has A as parent?" or even "what if there's somehow a null item in the list? What if the whole _list_ is null?"
Sure, most of those I don't expect to see in real life -- but if I do, I know that my code won't just crash / recurse forever / etc, it'll at least do something predictable. I've found a lot of bugs in my code by writing unit tests, and I'd much rather I find them myself, before code review time, and before QA time, and before it gets to customers.
A lot of the value, I think, comes from having to actually maintain projects long-term, which isn't something students are ever asked to do.
The main problem I inevitably have is that the things I want to check are things like "did these changes screw up the control loop". Which means interactions between the code, RTL, analog hardware, and the physical device I'm manipulating. In the places where the firmware is running most of the show I can drop in a simple model of whatever it is I'm replicating; in places where the RTL is running the show that's...much more difficult without re-implementing the RTL as part of the test.
One dream is to someday have a full simulation of the entire chip (RTL + firmware + a basic analog model) that can run through startup of the system--it would probably take a couple days to complete but man it would be cool. :P
I write almost exclusively in test driven development so I have unit tests for almost 100% of my code on a given project.
Which means I can change anything in the code that I want and I will immediately know if any of my functionality is broken.
Tests are green! This thing is taking too long, I'll optimize it. Oops, tests are red now. "Optimized" means "broken" evidently. Now not only do I know I've broken it, instantly and without having to manually run my program to check, I also know precisely WHAT about my code I've broken, since each part of the feature is tested separately.
Also you can hit conditions you know you'll need to test for but which are hard to replicate, like race conditions.
Unit testing is really invaluable for any project of any size, in my opinion. TECHNICALLY if your project is small or you don't need to support it long term you might use more time using TDD than by just writing the thing, but in my experience it's just a good discipline to do by default.
Every time I write code I run it to make sure it does what I expect. Might as well automate that check, right?
Visual Studio's Live Unit Testing.
For students who only need the code, really, to run once and whose entire time spent on the code spans maybe two weeks at most, it's not worth it. Or it's at least perceived as not worth it.
It's not that they don't test their code - well, some don't - but writing automated tests for every unit is actually probably not worth it in terms of time spent. They know the full scope of their project before they finish. They don't forget what the code does exactly because they wrote it four months ago. They (often) don't need to catch bizarre inputs from users.
I dunno. At the academic level, unit testing is one of those things that just never sinks in. I think sometimes we should abandon teaching it entirely and leave it to employers to train them up on, because it often feels like a total waste of instruction time down here. That or maybe we need to rethink how we teach programming entirely to wrap it around unit testing.
Plz no. Do you know how much it hurts in intern season when you hear "I don't get unit testing, why bother?" Even worse if they never hear about it, because now it's "well I wasn't taught this in school, and obviously they'd teach it in school if it were important!"
I don't know if this outlook is true, as pretty much nothing I learned in school was useful compared to what I have learned in the real world.
Interns! INTERNS!
Though really, total agreement on school vs academia. I have the furthest thing from a tech degree, but apart from some theory, nothing would have been helpful in what I would have gotten. (And as I don't really care to do proper CS/architecture/design, the theory is less useful than otherwise.)
The ones we "teach" unit testing aren't that much better. All they get of unit testing is in first year, there's maybe a week or so on it, they have to write unit tests for their assignments, and maybe there's a couple questions about it on the exam. And then it's promptly dropped and forgotten about for the next 3+ years, because we don't have the time to mark their unit tests, and they don't have time to make them.
Like, I think there's a whole big conversation to be had about what businesses want versus what universities can actually, effectively teach. Some things just don't square up well into 4-month terms, 2 week projects, midterms, and final exams. Like, teaching students how to work on big software projects: neato. Except running our 2nd term-long group project course is a huge pain in the ass, because students drop, students bail, and oh, on the side we're also trying to teach them Java, regex, UML, software design patterns, and version control all at once, and by the end of the project, they've written so much code that we don't have the TA time to review it all, never mind figure out how to mark it consistently, especially if we've been marking and giving them feedback throughout the term. Where the hell are we going to fit in unit testing?
I dunno. At this point in time, pretty much all my favourite undergraduate students have taken 5 (academic) years to graduate. Whether that's by taking an actual fifth year, or taking summer courses, or cramming in >5 courses in a term, or taking some remote courses while doing an internship. And these are my favourite undergraduate students, the ones with talent and potential that I keep tabs on after I teach them. At a certain point, I think the programming/CS community has to recognize that 4 years just isn't enough any more to teach grads everything they supposedly have to know, not unless we dramatically change how we teach it. I dunno how they're supposed to learn neural networks and deep learning in 4th year, when the first two/three years of the curriculum are basically still the same as they were when I did my undergrad 10+ years ago. As a community, we need to do a better job of figuring out what students actually need to learn in their 4 years, what can be delivered effectively, and how to deliver it.
(Sorry to get all existential up in your programming thread, y'all.)
The issue was in my game. All the communications were garbled. Turns out that there is a random modifier added of your ships communication system is just out of range. It depends on the the rand() function... Which is different in Linux and Windows
Windows:
//! Return random int /*! \param x range from 0 to x-1 \return random number */ int Rnd(int x) { float t; t = (float)rand() / 32768.0 * x; return((int)t); }Linux:
int Rnd(int x) { float t; t = rand() % x; return((int)t); }It would of been nice to know that rand() works differently each platform....
Though if you care about uniformity you shouldn't do divide by maximum multiply by n (this is especially bad if you are truncating, the maximum only occurs when you roll the maximum number exactly) or just mod by n. You would want to throw away numbers > RAND_MAX - RAND_MAX % n; you create n equal subsets, discard the unequal result range and hope you have a uniform RNG underneath
Honestly, I don't feel--and never have--that "CS" should be "the programming degree", or "the developer degree". What you learn has little to no vocational application, and hell, shouldn't. College isn't just "job preparation", and seriously, show me one software-related company that's anywhere near as sane as anything presented in a text. Why in hell is "version control" an academic topic, I mean? Best developer I've ever met (well, one of) is a former art major, after all.
This, however, is as well an existentialism.
Edit: And to @halkun yes, that is exactly why testing. "Did this thing I did actually do what I think I did, and did I break anything else I did?" Add time to the front end in test writing, etc, save EVER so much in "not trying to figure out why adding 2+2 is now equal to "cheese"."
This is one issue. Another is that "computer science" as a discipline has little to nothing to do with "being a developer" outside of very particular cases, and as an industry and profession, we're not doing ourselves any favors by conflating the two things. I mean it's like expecting your lab techs to have a degree in microbiology, or every single person working on your car to have a degree in mechanical engineering.
All that said, this is not me being in favor of the concept of "boot camps", because holy shit that industry is on the whole worse than for-profit online colleges... I just don't think "University" the way we're doing is the way to fix it.
A lot of people recognize that there needs to be a split, but so far, the plan of having colleges take over professional developer training and universities handle academic computer scientist training has not worked. For various entirely obvious reasons.
For example, why do we teach our students code versioning systems? Because employers said they wanted our students to learn it, and our graduates said we should have taught them. So we do. We could say no, we won't, that's for programmers not for computer scientists - not really since researchers have to have repos for our code too - go hire someone from the local college if you want someone who knows code versioning, but they won't and we won't so we are where we are, via inertia generating a collective action problem.
Yep. It's really... first-year CS is so completely different from most other first-year university courses. But there are all sorts of problems with high school CS programs, as they've been rolled out worldwide so far, such as not having $$$ for computers in many public systems, not being able to find CS people to teach for shitty high school salaries, lack of standardization and rigour in high school CS curricula, etc.. Most unis still operate as though there are no high school CS programs, because the high school students who have a significant CS background are so few and so inconsistent anyways, it's not worth revamping anything. Maybe they get to skip CS1 and go straight into CS2.
And companies will still prefer someone with a good theory background for those 1% of times where a cs degree is actually really useful in a day-to-day job
I wonder if this is changing though. As the tech industry booms and - I imagine - IT department growth has relatively stabilized - since all the large corporations already have their IT departments now - I wonder if the average nature of programmer work is beginning to change at all.
In an idealized world what would a cs bachelor's do when hired at a company, if not coding?
Switch: nin.codes/roldford
Good luck convincing the industry to do that or have anyone decide on what's important, though.
At college I have the opportunity to spend hours every week studying these things. I get direct attention from an expert whose job is to teach me this stuff for hours every week. I have the opportunity each week to go get one-on-one time with that expert to answer specific questions. College and university have a whole big support system to ensure you can learn that stuff if you actually want to learn it.
I have to send eight emails to four different people to get ONE of them to sit with me for half an hour, and it takes weeks to set it up and that's the only time it happens, because everyone is constantly busy with their own stuff they need to get done. And that's assuming they don't hit a crunch in the next couple weeks and need to cancel. There are people I can meet with spontaneously but if they don't happen to have the knowledge I need, guess I'm sending out emails and praying.
Education should absolutely be providing as complete a theoretical framework to students as possible, which includes versioning, testing, debugging, etc, and essentially nothing except implementation details should be learned on the job.