(I've written probably 300 API tests since I started here, at least doubling the testing, there are still plenty of untested or nearly untested endpoints)

Our tests are generated by some custom code a guy before me wrote to create boilerplate for a swagger-express-mw based node app. Then we flesh out the business logic, data access, and testst. So at least I don't have to write that nasty Regex stuff from scratch every time. The code I posted was largely generated.

As far as validation swagger-express-mw does a check of the return data and input data against the model or field, and throws a validation error if they don't match. IE - required field is missing.

Right, that part is easy, what I want is more than that

At least in our app, I don't see how it could be any more automated w/o the generator having to guess at your business logic and back end data access logic.

What else exactly are you trying to automate?

Well, RAML lets you give an example return document from a call. A good start would be validating that the values returned are what you expect - not just whether the fields exist and are the right type, but whether the values are correct. It should/could use the example document to do this but I have not seen any RAML testing frameworks that do this.

In my prototype I had something I called contract. They basically defined flows of data, along with specific guarantees. For example, consider an "add user" contract
a) get list of users
b) add user Alice
c) get list of users
d) new list of users should be same as first list of users, but include alice
I would cobble together these tests by using the examples that I provided with the docs, plus a little glue (i.e. constructing the test for d from a + b)

I bought my first computer about 6 years ago. I had to go to a friend's house to figure out how to turn it on. Granted, this wasn't a matter of pushing a button, but still...

I got my first office job 5 years ago, which required me to turn on the computer when I walked in. I took a deep breath, pushed the power button, and prayed. Miraculously, the computer booted up entirely, and I'm sure I'd have no clue what went wrong if the screen power button wasn't on that morning. I was now amazing at computers in my little world (holy ****, I can turn one on!), but that day... I was using Excel and Illustrator. I never used the former and never knew the latter existed. The only thing that saved me from not being fired on day 14 was crying my eyes out when the owner told me the bad news.

Technophobia is a real thing, but it can be overcome with persistence.


mechanical keyboards, seriously. My hands used to burn every night and I did contrast baths to get through the pain. That $140 was the best money I ever spent. (also, minimize mousing)

But why aren't you seeing a doctor for this? This sounds serious. They can, at the least, give you medicine, some advice, and perhaps prescribe Rolfing.

I feel like you have misread me. The one thing I absolutely hate to do is give up. You only give up when marketing and management has merged their range (imposed the impossible on you). Either one of them individually imposing some set of restrictions on new product is (at worst) hard to overcome. It's when they unite that it becomes exceedingly hard (or impossible).

Everything is knowable in time. Key phrase here is 'in time'. Given my current knowledge, those weird column duplicates wouldn't have been an issue because i know how most things work now. Keep in mind that when i was assigned this task of migrating over lots of legacy PHP I knew basically zilch about how everything was setup/organized.

That's great to hear! Keep it up

The fact that i know how stuff works now does not excuse the fact that the **** that tripped me up originally still exists. In my quest to refactor legacy code, I still find columns that serve no purpose. Literally, 100% of the values in that column are identical.

It seems like you're in a good position to fix it!

In order to get it fixed, I would have to put in a request to one of the dba's to fix it. I can't even get permission to fix things that make less than no sense in my own department (ui). I think you make the assumption that 'hey something that makes no sense go fix it!'. That's not how it works. It's very very very hard to get something changed unless it literally breaks something in production. This is a case where it breaks nothing... its just stupid and ****ed up. I have pointed out several things that fall in the "stupid and ****ed up" category. To date, i have created branches for all of the cases like that. They all sit unused in branches that may some day get merged into master. It massively irks me that I can sit around all day fixing broken pages and never have any of those fixes make it into production because they generally address edge cases that I happened to discover but customers are unlikely to discover.

This is from my textbook:


The author is incorrect here, right?

edit:


This compiled just fine for me. Am I doing something different from him? (the green swiggly is just b/c it's never used)

Yes, you are. To be doing the same thing as the author, you would have to do something like

I still don't know if he's right because I don't make a habit of duplicating member names as local variables in my C# code, but that's the difference.

Ahhhhhh okay. So the line that he says is invalid is only invalid because of the line which follows it. If you comment out the next line, the line he said is invalid becomes valid (I tested this by doing the commenting out). However if you leave it the way he wrote it and changed M = N to M = this.N it is fine.

So would that code be valid in C++ and Java? If so I think C# has that right, I mean there are zero positives for allowing partial block scope, it just provides an extra opportunity to write bugs into your code. Obviously TRWTF here is using the same name for two variables.

Not sure I'll try it later. Although this could be used as an argument for making more use of the "this" keyword even when you think it is redundant or obvious. If you use "this.N" in the examples above it works fine and will compile.

Is this an okay way to think about dynamic scoping vs static scoping?

Static scoping uses the outer-most variable (when ambiguous)
Dynamic scoping uses the inner-most variable (when ambiguous)

also, why not just disallow ambiguity and be done with it? I guess if you import a library and were no longer allowed to use any name that was used in that library that would be annoying. but you could just say "u need to use lib.name or this.name, because using name is ambiguous"

Personally I start all my member variables with an underscore, so the question never arises. That's personal choice though.

Start them with $ because then they are cash.

That's incorrect. One simple way to think about it is:

Static scoping uses the callee's scope
Dynamic scoping uses the caller's scope

For example,

With static scoping, y will be 5 - with dynamic scoping, y will be 4.

This is a completely settled debate btw - static scoping (more commonly called lexical scoping iirc) has won.

You can't do recursion if you disallow all ambiguity with dynamic scoping.

Edit: I misread the earlier example - so I'm talking about something related, but different.
Edit: And looks like this behavior is the same as in Java.

It's interesting because C# has proper block-level scoping in terms of language semantics but disallows the same name in a method. This works as expected:

=>

The only way this can work is for each iteration of the loop to have a separate block scope. The pre-ES6 JS equivalent would print 10's because it doesn't have block-level scoping. From a language design perspective, it's interesting because C# is checking for and disallowing things that are perfectly unambiguous from a language standpoint because they thought it may be confusing for the developer. It's like a built-in lint.

In C++ and Java, are they hoisting the other declaration up or simply translating the former into this.N? The former makes sense, the latter doesn't.

Edit: Looks like they are translating the former into this.N. Maybe this looks insane to me because I spent too much time in JavaScript.

They're translating the former into this.N, I assume. That's what the author meant by "whole-block scope", i.e. in C# N is in scope for the whole block, yet not declared, whereas in Java/C++ N is only in scope after being declared, prior to that "N" means this.N.

It might "make sense" but it seems pointless and an invitation for bugs to me. Intuitively it seems to me like a whole block should operate with the same scope.

You have to fix the process first - it's likely that the reason why you can't get the permission to fix things is that the process is broken. It's likely that within the process they have and the view they have of you, it's rational not to allow you to fix things like this because you or others can't prove to them that the fix won't break the application.

Oh just realized you were saying that translating to this.N doesn't make sense (or maybe I read it right first time and you ninja edited?). Anyway yeah, I agree, interpreting it as this.N offers zero advantages and plenty of scope, no pun intended, for horrible bugs.