I was recently asked to help our Spanish BU to audit their AD for inactive accounts.
Grabbing a script from online I gave them this: https://gallery.technet.microsoft.com/scriptcenter/Get-Active-Directory-User-bbcdd771
However that doesn't scale well when there's multiple users; as this takes o...
But these integration tests.... should they be JUnit and runevery time you build your project, or should they be run less frequently as part of something else?
One difference that can be important is if integration tests are much slower. Then it makes sense to put them in a category to be run separately, for example nightly.
@JohanLarsson I normally prefer integration tests, but in this case I feel like my tests shouldn't perform an actual request to a service to close a ticket..
Either that means that your system under test does too many things at once (and that makes it hard to test and brittle) or your test is doing more than one thing (which means you'll likely miss edge cases, at the very least)
var command = new AsyncCommand(() => Task.FromResult(1));
Assert.IsTrue(command.CanExecute());
Assert.IsFalse(command.CancelCommand.CanExecute());
Assert.IsInstanceOf<Condition>(command.Condition);
You're making 3 assertions here in a single test case
One assertion per test is probably not the thing to go for, but it's an easy way to say "This is only going to fail for one reason and one reason only"
If you have one test with 10,000 asserts, it can fail for 10,000 reasons and you have 100% failure rate. And all the build server tells you is which test failed.
I have been working with HTML5 and CSS3 for a long time now, but have avoided JavaScript because of my belief that it's most frequently used unnecessarily while having a tendency to be poorly written. So I held off until I needed to learn it to use something really cool and useful. The project ...
If you don't find having one reason to fail per test productive, great, that's fine.. but remember that one of the tenets of good software is each class having one reason to change/fail. If you're having to have more than one assertion to test - or have "test bloat", you're either making brittle code or violating SRP
Which highlights the advantage of tests... If you are satisfied that your tests cover all of your acceptance criteria, you can refactor out from under it with the comfort that your automated tests handle the acceptance criteria.
@DanPantry If you write a line of business application for handling payments. The code that produces the exe is application code in my definition. If you write a general purpose tool like an IoC-container I classify it as library code.
@JohanLarsson I'm a JavaScript developer, while we don't have exes, we generally have two projects in applications. We have one 'library' project which uses many modules etc and is tested. Then you have another project that puts it into something runnable.
Example, I build a user interface using React in one project. This stuff doesn't actually touch any real itnerface, it's just functional code, so I can test that.
Then I have another project that actually renders those actions into the DOM, or a HTML string, or.....
But everything else is testable and for all intents and purposes could be a library that could be re-used
In my current code base for my very really project for the iOS app store, there are exactly two things that are hard to write good tests for...
1. The very thin Objective-C wrapper over a C++ library (the C++ library has its own tests and is outside the scope of my concerns). 2. The very thin layer of user interface code (which is tested with functional UI tests).
There's a lot that goes in the middle that we test with unit tests.
@JohanLarsson If refactoring is likely to effect the public API, it's generally going to be because the public API has problems. And if you really took the time to fully test that public API in the first place, you're far more likely to notice the interface's problems while writing the tests.
@DanPantry I feel like I phrased something poorly sounding aggressive. Did not mean to belittle you. Still think the ping me in five years is a sensible way to think of it. I expect/hope that I will be doing many things differently in five years. A critical attitude always trying to improve is a good mindset. What does x buy us? What does it cost? Can we do it in a better way? For all things.
@JohanLarsson No offense taken, it was an honest admission from my part (and not triggered by anything you said). I am fully aware that I have strong opinions that I may come to regret in time for someone so inexperienced (relatively) in programming :)
Agreed, making a new project is like heaven compared to migrating this mess of an app from eclipse to android studio without making any logical directory structure changes. Old problem of having too many independent devs working on the same project without code review.. — Ryan Stush53 secs ago
The use of bitwise operators is generally forbidden/frowned upon in the common JavaScript coding standards. So if you're using a linter (jshint, eslint etc.) chances are you won't get this through code review. Solution works though. — jhrr36 secs ago
This class simply allows you to use an enum while only allowing you to set a single flag. If multiple flags are set they will be rejected--unless the total of the combined flags is the same value of an existing flag. Such as Flag1 | Flag2 == Flag3 would be an example thereof.
C# 6.0:
public cla...
So I have code to create a matrix, in this case it's limited to 3x3
public void insert(DatagramPacket s) {
// 00,01,02
// 10,11,12
// 20,21,22
//System.out.println(x + " " + y );
if (y == 3) {
y = 0;
}
if (counter <= 2) { //3
...
the only thing I don't like about it is that the hole for air is at the bottom, so the natural squeezing position doesn't squeeze because you're blocking the hole with your hand
@EthanBierlein here is how you have to do it if you want to use the Posts.Tags column (which in the background is really plain text, but that is hidden because of the magic SEDE rendering of tags) : data.stackexchange.com/codereview/query/441034
And if you click delete, you only get one chance with confirmation, if you are not paying attention and click OK it DELETES THE APPLICATION FROM PRODUCTION
The stickers are printed on vinyl and laminated so they should hold up pretty well. That being said, I would not recommend putting them in the dishwasher. The stickers are also removable/repositionable, so my guess is they have the potential to come off during a car wash/dishwash. — JNat ♦Jan 21 at 17:56
so I guesssss you could take off the sticker, wash it, then put the sticker back on...?