• Edd (unregistered)

    Return fisrt_Comment

  • (nodebb)

    Bonus points if the source code was delivered as .docx.

  • WTFGuy (unregistered)

    Said .docx including bits of formatting / styling that, if dug into carefully, clearly show the copypasta came from stackoverflow or some such. I just love paying full HPC price for that stuff.

  • WilliamF (unregistered)

    That looks like a student assignment I graded once in CS102; it had been typed out in Word and handed in as a .doc file instead of a .java file.

  • Steve (unregistered)

    It's a while since I did any C#, but my eyes also started twitching at using an object array rather than one of the .Net framework data-specific types ... and after all that the data wouldn't actually display anyway, because there's no .DataBind after the .DataSource ...

  • (nodebb)

    How come it you did not see that the publicproperties are created for unit tests such that you can see that everything is parsed and executed correctly?

    Oh wait, unit tests. Did the HPC deliver them or just offered them at a really high price?

  • Hal (unregistered)

    Is this real? I have my doubts. How would someone with enough ability to speak even the right buzz words required to get the contract not be able to at least install VS Code or the Free Version of Visual Studio?

    Either of those things would have made the capitalization of at least the reserved words correct without extra effort. I would think even someone completely misrepresenting their ability would want to try to produce something they could at least attempt to bamboozle some jury with if they got sued.

  • Cidolfas (unregistered)

    Oof, the combination of Capitalized_Snake_Case and CamelCase offends me at a molecular level.

  • Sole Purpose Of Visit (unregistered) in reply to BernieTheBernie

    PrivateObject/PrivateClass are your friends for this particular issue, btw. Unit tests shouldn't have to care about whether classes and/or objects are visible to the "outside world."

  • Sole Purpose Of Visit (unregistered) in reply to Hal

    Well, it could just be a straight copy and paste, with no effort even to compile it.

    Or it could be from an entirely different IDE, say RIder 1.0. (I'm not knocking Rider. I imagine it's excellent.) For all I know, other IDEs don't check that stuff.

    Or (my personal guess) it was written in VB.NET, which doesn't give a rat's ass about case sensitivity, and either forced through an online translator or manually frobbed.

    At the end of the day, the WTF is why anybody would pay for something that doesn't even compile. Cowboy coders exist because cowboy management allows them to exist.

  • Erk (unregistered)

    You know what they say... fake it till you make it!

  • Erk (unregistered)

    You know what they say... fake it till you make it!

  • Foo AKA Fooo (unregistered)

    You mean "we use LINQ to NOT filter", because the filtered array is stored in "results" which is not used. Instead the unfiltered "Results" is stored.

  • (nodebb) in reply to Sole Purpose Of Visit

    PrivateObject/PrivateClass are your friends for this particular issue, btw.

    It's probably not a great idea to root around the internals of something you're testing. You end up with fragile tests that will detect "someone changed the thing" rather than "someone broke the thing". If you end up doing this sort of thing more than occasionally, then you should be changing how you code, rather than figuring out how to test hard-to-test code.

    Writing this code better would show that there really isn't any flow to test anyways. I'm pretty sure the code can be reduced to:

    protected void Page_Load(object sender, EventArgs e)
{
	OrdersRepeater.DataSource = Repository.Search(Request.QueryString["Search"], IsActiveEnum.All);	
}
  • Sole Purpose Of Visit (unregistered) in reply to Jaime

    I accept your general point.

    However, unfortunately, we're dealing with .NET, not with Python (or similar). Chances are, you're going to want to write unit tests for a C# private method. With python, you'd just use main and so on. With C#, you have the following choices:

    1. Make everything you want to test public. This is obviously not a good idea.
    2. Provide some sort of artificial public access to a private method. This is not obviously a better idea.
    3. Use what the test environment gives you, which is PrivateObject/PrivateClass.

    Thing is, if you use MSTest or its little friends, your test system sits in a separate project. You can fool around with references and so on, but I can't see a good reason not to use reflection.

    In fact, this is almost the only good reason I can see to use reflection. (Other than for Winforms and so on, of course.)

  • Sole Purpose Of Visit (unregistered)

    (That's underbar underbar main underbar underbar, sigh.)

  • (nodebb)

    I imagine this being written under the influence of some brain retarding drug.

  • (nodebb)

    Regarding testing, WebForms aren't easily testable themselves, but the good news is that WebForms code should be concerned with UI only and therefore should be tested using UI automated testing tools, not unit tests. The underlying logic, such as the repository, can and should be tested, regardless of the front end.

    And no, there should never be a need to test any private methods. The definition of testing is comparing the result of an API against its declared public interface. Note the word public. If there are private methods which need testing, it means the class is too large and chunks of its functionality need to be extracted into other, smaller classes and interfaces, ie. modularized.

  • Sole Purpose Of Visit (unregistered) in reply to Mr. TA

    Your definition of testing is not mine.

    If I write a unit test, I want it to be a test on a "unit." It is up to me to define what a "unit" might be.

    Let's say you have a private method that, given a Voronoi diagram and a point, returns the nearest Voronoi point to your point. You really are not going to want that to be public, or even internal. Or perhaps you do want that, and you'd rather have a big lumpy "everything is public" MS solution. I'd rather keep things like this inside the geometry namespace/dll, thank you very much.

    I'm not advocating using reflection all over the place. I'm just advocating using it in specific, controlled, non-production areas where it makes testing easier.

  • (nodebb) in reply to Mr. TA

    The definition of testing is comparing the result of an API against its declared public interface.

    Be careful of the difference between blackbox testing (which is what you defined) and the more rarely-needed whitebox testing, which involves knowledge of what's inside.

    And neither integration testing nor system testing have any relation to APIs.

  • (nodebb) in reply to Sole Purpose Of Visit

    How you package certain features is a different question, you can have a geometry DLL, etc. However, the Voronoi diagram calculation is a distinct, complete, testable feature; it should have an interface and a unit test against that interface. If you want to hide this from the consumers of your software, say, you are shipping a solution and you don't want these geometry features available, in .NET you can make them "internal" and then expose them to other DLLs in your solution using "InternalsVisibleTo" attribute. One of the DLLs mentioned in "InternalsVisibleTo" will be your test project.

    In short, I wouldn't conflate feature verticals/packaging/deliverables/customer expectations, with testability.

  • (nodebb) in reply to Steve_The_Cynic

    To that I say whitebox testing is entirely unneeded, IF software is correctly architected. I understand the need to test control flows and various quirks of the implementation, but all of those should be captured in the requirements/API contract. This process is iterative; nobody says that some "boss of requirements" dictates everything and programmers need to implement all of them come hell or high water. Obviously, programmers find edge cases/control flows, the requirements are then modified to include those, and then tests are updated to reflect these edge cases. Skipping the contract/interface and jumping straight from implementation to tests is a recipe for problems.

  • Sole Purpose Of Visit (unregistered) in reply to Mr. TA

    Never even heard of the InternalsVisibleTo attribute. This is a welcome addition to my knowledge base.

    Guess what it does, though? It uses reflection, just like PrivateObject/PrivateClass!

    So, actually, no difference at all. Look, I'm not arguing for splurging reflection all over the place. I'm just arguing for sensible and confined usage. Whichever flavor of reflection you choose to use is fine by me, because it's easily constrained in either case.

    Having said which, it's a pain in the arse to go back to the called site and add an attribute. Which may need an update in future. No, I'd rather add my reflection at the calling site, where with my "testing but that's all I do" hat on, I don't need to mess around with internals.

    I might also add that adding attributes is not really an option in third party software. Of course, you might poo-poo the need to write unit tests for third party software, and obviously you are never going to need to upgrade that third party software, so once it's there, it's there.

    In which case, allow me to poo-poo your poo-pooing.

  • (nodebb) in reply to Sole Purpose Of Visit

    I'm not sure what you mean by "InternalsVisibleTo uses reflection". When DLL A exposes its internals to B, you build B and A's internals are visible just like they were public. I'm pretty sure this is done by the standard linking logic of the builder, not reflection. However, even if you were right and all references in B to A's internals are compiled to reflection calls, it's still preferable because you have the guarantee of the framework doing all this for you and none of the dirty reflection calls in your code. Either way, there is a huge difference.

    Secondly, your point about the extreme amount of work needed to add those attributes is kind of weak; it's a one liner which you change very infrequently (how often do you add projects? once a month, at most?) Yes, it is POSSIBLE that you have a 3rd party DLL inside of which there is a private method which you want to test, but that's the most unlikely scenario ever in software engineering. You can't really do it regularly, because as they ship new versions, you need to continuously update your tests; there are questions as to why you are testing a 3rd party paid product (paid because if it was open source, this isn't a problem - you can modify it as you need and make these endpoints public or "internal"); and even if you find bugs in their internal methods and raise it with the vendor, they'll likely say, we do not guarantee anything about how our private code operates, in fact please stop reverse engineering or our lawyers will be calling. Most importantly, whatever that 3rd party software does for you, it is exposed publicly and can be tested that way; you can then ask them to fix a bug which violates their promise to you - if they don't, you can (theoretically) hire lawyers to call them - a much better position to be in.

  • Eluvatar (unregistered)

    I'm surprised no one has mentioned this yet:

    from r in results where r.isActive select r

    the type of results is object[], so the type of r in this case is object, object does not have a field or property called isActive so this shouldn't compile either.

  • Rob (unregistered)

    If this is anything like Java's servlets, and a single instance is used to serve many requests, then there's even a major concurrency issue. If two requests come in at the same time, you don't know which of them will have set the SearchText that's used in Search. You could end up getting the search results of someone else!

  • Naomi (unregistered)

    Off the top of my head, I can think of one really simple case where limiting your unit tests to the public API makes everything harder - when you've got a factory that returns different implementations of an interface with nontrivial behavior. I think we can agree that the concrete implementations shouldn't be public, but should be tested. You could write a really complicated test suite for the factory, but I'd find it a lot clearer to write tests that check the factory returns the correct implementation, then test the implementations.

Leave a comment on “World Class Contracting”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article