4 ms·

We are language and environment restricted to waterfall at my job. The language does not have any form of unit testing and an extremely archaic version control.

by ambiate 13y ago

We are language and environment restricted to waterfall at my job. The language does not have any form of unit testing and an extremely archaic version control. The language does not have a viable way to encapsulate small changes without coding the whole shebang. The environment itself follows some of the same pitfalls. CD sounds amazing in theory, but some languages simply do not fit into the paradigm.

Joeri 13y ago
If your language has a way to put an if condition around a block of code and change the value in the if condition at runtime, then you have enough to hide experimental changes behind a flag. If your language has a way of calling an existing block of code from a new location and checking the results, you have enough to write unit tests. I don't know any languages which are unable of those things.
- jdlshore 13y ago
  Some business-critical DSLs are indeed this bad. Think "business process modeling" tools that are intended to be programmed through a GUI.
- Jtsummers 13y ago
  I can't think of languages, but I can think of environments where it can be difficult. Maintaining software for embedded systems developed ages ago, for example. Unit testing of your new algorithm is, on the platform, not feasible. You may be able to put the code segment and mock up the rest of the software/hardware environment on your PC, but then you'll find out about undocumented features when you push it to the platform, or performance characteristics that make one algorithm less suitable than another (memory usage, time consumed). And you have to persuade those above you to give you the time to do this, when they don't see the value and want to get the code changed, reviewed and pushed to their normal testing procedures (which might be white-box testing, but is likely black-box testing at its finest). And when your office has been built around this model for years, decades likely, introducing unit testing for new desktop apps (support apps like I make), is hard because they don't see the value of it. They have a process, I should just stick to it (that's their attitude, not mine).
kasey_junk 13y ago
Can I ask what language doesn't have any form of unit testing?
- silverbax88 13y ago
  Not sure about the OP but any procedural language would run the risk of being very difficult to write unit tests for, especially some of the ancient chron file based languages that a lot of U.S. manufacturers still rely on. But hey, most programmers today (wow does that sound like an old fart) don't know there's a difference between event-driven programming and procedural programming, because all they've ever worked on is event-driven.

by ambiate 13y ago

Joeri 13y ago

If your language has a way to put an if condition around a block of code and change the value in the if condition at runtime, then you have enough to hide experimental changes behind a flag. If your language has a way of calling an existing block of code from a new location and checking the results, you have enough to write unit tests. I don't know any languages which are unable of those things.

jdlshore 13y ago
Some business-critical DSLs are indeed this bad. Think "business process modeling" tools that are intended to be programmed through a GUI.
Jtsummers 13y ago
I can't think of languages, but I can think of environments where it can be difficult. Maintaining software for embedded systems developed ages ago, for example. Unit testing of your new algorithm is, on the platform, not feasible. You may be able to put the code segment and mock up the rest of the software/hardware environment on your PC, but then you'll find out about undocumented features when you push it to the platform, or performance characteristics that make one algorithm less suitable than another (memory usage, time consumed). And you have to persuade those above you to give you the time to do this, when they don't see the value and want to get the code changed, reviewed and pushed to their normal testing procedures (which might be white-box testing, but is likely black-box testing at its finest). And when your office has been built around this model for years, decades likely, introducing unit testing for new desktop apps (support apps like I make), is hard because they don't see the value of it. They have a process, I should just stick to it (that's their attitude, not mine).

kasey_junk 13y ago

Can I ask what language doesn't have any form of unit testing?

silverbax88 13y ago
Not sure about the OP but any procedural language would run the risk of being very difficult to write unit tests for, especially some of the ancient chron file based languages that a lot of U.S. manufacturers still rely on. But hey, most programmers today (wow does that sound like an old fart) don't know there's a difference between event-driven programming and procedural programming, because all they've ever worked on is event-driven.