Maximum PC

Actually, the idea behind writing the tests first doesn't require you to compile them. You're checking that the design/interfaces you've created work in the way you intended before you spend time implementing the code. If the unit test code is difficult to write or use, then you know that you need to go back and redesign before doing the implementation.


Actually, DJ brought up a valid point. In the past few years, it has become more and more popular for teams to distribute their code with the tests to ensure the software will work on the customer's computer (usually for in-house software).

My only experience with unit tests was in a compiled sense. Everything in .NET is compiled, so ?? interfaces have no implementation. How can you test that it works without implementing something that uses the interface? I have never had the chance to work in a company where anybody had "time" to do "proper" unit testing or TDD. Even on the new code that I wrote there wasn't any time built in for doing anything but normal testing that you should be doing anyway.

I am sorry, but that is stupid. If developed correctly there shouldn't be any reason why your tests would need to leave your development and QA environment.

Unit testing ensures that the code behind is proper. I unit-test all of my libraries that I wrote - and I mean, *ALL*. No one wrote an Active Directory Library for us, so I wrote one - used Unit Tests to prove that my AD calls are right, I used to check the objects being returned and I used to ensure that I'm parsing my stuff correctly. Once each unit test passes, I implemented the code - refactored as needed.

Unit testing is also good for fleshing out more behavior: implementing an interface, running tests is just one way of testing an interface. However, if you find yourself testing functionality but need to split an interface, then the split happens locally in the test. You can retest the new split interface by refactoring and re-running your unit tests...this way you always ensure that the code you implement is 100% tested. The amount of time I spend testing is negligible considering that if my manager asks me about my code, I can at least guarantee a level of code-coverage (60% is ideal for me, since I'm a lone developer).



Because testing code is different from testing a final product - even in test environments. Testing in a development or QA environment tells me something about the run-time, but as errors crop up, it gets more and more difficult to track where the error occurred. I live in a world of tiny budgets (or none at all), so it's not like I can go and purchase profiler tools from Red Gate. So the next best thing? Unit testing. Also, if you open source code, including your test with your code enables other developers to understand the functionality of your program through tests. This is why I'm a big fan of BDD.

Anyhow, for me, testing is important and Rails facilitates that desire. The automated tests is a great way to streamline my productivity, partly because I don't need to switch projects!

No experience with them. I haven't even heard of them.

I had a similar experience with Dice. It is nice to know that there are lots of jobs for those with talent.

I still disagree with releasing test code with your application. I have automated error logging and such that can send specific details back to the developer. I don't see how deploying your application with the test code does anything for issues that crop up in the wild. You don't need profiling tools to find errors.

In F/OSS that is different. Leave it in the repo.

Testing is most definitely important! I wouldn't try to dispute that at all.

You DO NOT have to "switch" projects! I really wish I had time to create a sample VS solution so we could look at a concrete example. A visual studio solution has many projects. You just open the code file! In VS 2010 you can even have them side by side on a dual screen system and read both files with ease. I still am not seeing how keeping the code/tests logically separated is a downside.

I've heard of them, they're like every other large recruiting firm - hit and miss. Sometimes, they do a good job and get my feet in the right doors, but other times, forget it. In the years I've worked, 100% of my jobs have been obtained through my own searching. Never has a recruiter partnered me with a good company that I actually wanted to work with.

That being said, they do have a good reputation. I believe we used them when I worked at the bank, so they at least have a large pool of talent.

No no no... you're thinking in terms of compiled vs interpreted languages. The reason that XP advocates suggest writing unit tests first is because you want to "exercise the design" to make sure that the interface you've implemented is solid in the "I really like using this API sense". Writing the unit tests first forces you to use your own design and hopefully prevents you from becoming the guy that wrote something fugly like COM.


Why don't you consider unit testing to be "normal testing"? The TDD guys would argue that TDD actually saves time in the long-run. You know the whole "bugs caught early cost less" thing from SE courses.


Actually, if the code you write depends on many external libraries, then distributing the unit test code will often save you a lot of trouble. At Boeing, despite the companies best attempts at ensuring that everyone had exactly the same software installed, there were dozens of people with JVMs that were over three years old. I'm not really for or against the practice. In the worst case, it blows up your code by maybe 200K. Not really a big deal considering the abysmal quality of most developers algorithms and data structures (knowledge & implementation).

Actually, I find unit testing to be far and away the most worthwhile kind of testing... especially when working with lousy programmers (they're the ones that argue the loudest about how THEIR code couldn't possibly be at fault), when inheriting/maintaining code that you didn't write (esp libraries), or when integrating code bases. The original rules engine that I mentioned in the other thread had tons of errors. I seem to recall writing unit tests for something like four hours straight (after lunch) and then filing something like 60 change requests the next day because the people who originally wrote it never wrote any unit testing. They weren't really proactive about testing... more of the lets do an acceptance test and let the system engineers file the change requests when they find errors. The unit tests were the straw that broke the camel's back and allowed my manager to get funding for us to rewrite the damn app. I probably could have found 500 errors if they'd given me enough time.

The same team had a set of something like 400 or 500 SQL queries/checks that was supposed to be an indicator of the maturity of the data in the database. The system engineers really believed these things were gold. Most of these queries had been around for better than 10 years and were 'bullet proof'. After looking at a few of them and realizing they smelled to high hell, I used one of the database testing frameworks found out that SIX of the first TEN queries that I tested were wrong!

1. Never trust any code that isn't unit tested.
2. Always write unit tests for your code.

Regarding regressions errors: automated unit testing is far faster, cheaper and more complete than any kind other kind of regression testing that I've seen done. I'm also a big believer in the idea that if you can't unit test piece of code then your design is bad (w/ some exceptions for web apps and database code). Time to refactor.

Why? Do you like punching yourself in the dick when you program?
OK, so I was having trouble imagining what is big deal about Intellisense (because I didn't remember it being different than any other autocompletion system) and took a glance on wikipedia...


So what is the big deal? EVERY IDE does this.


What are you calling a pre-live environment? Is that some new terminology for a web app/database testing framework/environment or just a test server with a test database?

And a lot of people run their unit tests whenever they build Crashtech. That is actually one of the XP commandments.

Right. I wasn't under any impression that they didn't. I just don't see why you wouldn't use it and any other facilities that aid in increasing the speed at which you write code.

The way I see development working (unit tests is one thing btw, It isn't the be-all-end-all!) is the developer has his local box and a development environment. A place that he can trash however he (or she, whatever) wants to. Then there should be a test environment where the system can be reviewed internally. Pre-live (staging, QA, whatever you want to call it) should be an exact copy of production. Both hardware and data. The thought with this is that you could do load based testing and put some real clients in the system.

In an ideal world, once you have the code up and running and verified, I would swap production and pre-live. The pre-live server is now live production and vice versa. It removes chances for human error with deploying code and configurations etc.

I am not against unit tests, seriously I am not. After having a few years of experience, a lot of established companies aren't likely to adopt all of the new programming "fads" (you know there will be new stuff in a few years that will replace the current paradigms). There just isn't time or money to make that change and still keep up the run the business costs. The only way would be for developers to spend countless hours of unpaid time (yeah right, are you kidding me?) to make the changes quietly behind the scenes. I have been VERY hesitant to do anything like that. Because as soon as I do, it will become expected. I think 40 hr work weeks are ridiculous as is for a variety of reasons, and I won't set myself up for an expected 50 hour week.

I understand that DJ is disenfranchised with the business world and for the most part Gadget is an academic. But the two worlds are very different. Things are slow to change for the vast majority of companies. They have massive code bases that it just isn't feasible to re-write or to start building unit tests. You just have to make due with what is there, and often a lot of it is very, very bad.

TDD is great for NEW development. However I'd argue that a very high percentage of development work is not brand new.

Hehehe, disenfranchised? Maybe...but with MSFT and their direction. The business world can be invigorating, if you work or follow the best people. I often follow the guys at 37 Signals, they are a breath of fresh air in the business world. Lately, I've been reading Rework (from the same guys at 37 signals) and want to pick up a few books from Zappos' Tony Hsieh.

I don't like to think of myself as a disenfranchised programmer. Bored? Sure.



I think Gadget hit the nail on this one. Even with existing development, TDD is great. TDD allows for faster ramp-ups because the entire user-story of the application is contained in tests, so it's literally a requirement spec told in the story of test. Instead of spending hours looking at the application, look at your TDD test cases and you get a high-level view of the app.

I agree with Gadget that it can be used to test existing components for validity in older software, it can also be used to test old-code tie-ins with new-code. TDD has great value, it's not just a "new development" deal.

One more thing; if you use BDD tools like RSpec or Cucumber, the test cases are actually readable.

I know we kind of got off on a tangent, but to get us back to the original topic... I think DJ's post might have been a bit too early (I know I was concerned with the Win8 announcement about HTML5 and JS, like many developers). It is still way too early to tell but I wouldn't count Microsoft out yet.

http://arstechnica.com/microsoft/news/2 ... reborn.ars

I think that WinRT is exactly the thing you were complaining that Windows didn't have.

The biggest paragraph from the article is this one:



I know I am the resident MS and Windows "fanboy" here, and I have no issues with that! I am totally a huge supporter of MS and pretty much always have been. That isn't to say that I am against other things, if anything I am for them. Why? Because it has finally forced MS to stay on their toes and work doubly hard to make things better. At the same time, F/OSS needs to keep moving (as they do have some ground to still catch up on even) to push back. This is exactly the kind of "competition" that fosters rapid and advances and new development.

Color me excited again!

It seems really cool and all, but it's ten years too late for me.

This philosophy should have been adopted back in Windows Vista - back when .NET was at the height of her fame. From what it seems, they're using the word "peer" to really mean "parallel". The native API's and .NET will appear seamless and will work together as "peers" but what they seem to mean is that they will work in parallel to each other. That is, .NET is still being given that shaft (IMO).

My biggest complaint is that MSFT should have standardized years ago and used a singular framework rather than this crappy duopoly. .NET was an excellent platform that they never really, fully capitalized. Now that they're finally standardizing to WinRT - I think it's great, but a little too late for me.

Yes, but you haven't given us a good reason WHY you shouldn't do this. As far as I can tell there is no harm in it. Sure, you mentioned alternative that everyone does like...


You're basically saying "Yeah, if there is an error, I'd like to know about it." When an exception is thrown, you'll get back a call stack and (hopefully) details about what arguments were passed to a method, right? This is good information to have when diagnosing a problem that you did NOT anticipate, but critically, it is still a reactive treatment for dealing with errors. With the unit tests, you'd be saying "I want to make sure these things won't be an issue."


The people running your code may be using a different virtual machine or architecture, might have a much slower or faster network or database, might have a bad set of libraries installed (ie DLL hell). Hell, one time we had an internal team that was using the wrong version of the database schema (granted, it wasn't our fault they were idiots, but we still had to hunt down the problem). Natually, you won't be able to write unit tests to cover all contingencies, but whenever something does happen, you can then write a unit test and know that it will be easy to diagnose if it ever appears again on another machine/environment.


Let's pretend we've just changed a bit of existing code together in VS that already have unit tests. Can I now press the F10 key (or some other function/shortcut key) to run the existing unit tests?

Quoting Joe Rogan in the context of people being paid 20 cents an hour to make Nike shoes... "Uh, THEY should probably quit their jobs, but I don't know how to make a pair of shoes so..." =)

Usually it is an evolutionary process, if someone tells me to find a problem, I'm going to hunt down the problem and solve it and write a unit test(s) to ensure that it doesn't reappear (and assure myself that I actually fixed it). On average, I'd estimate that writing unit tests takes up less than 10% of the total time for a change request. Before long, you have a nice set of tests and fewer problems.


True. Many (average) companies do have large code bases; Most of the code sucks pretty bad too. However, I don't think the problem is related to the cost of writing unit tests. In fact, I'd speculate that writing unit-tests saves companies a fortune in the long-run. It only takes a minute (to write) but can save an hour. Aside from a couple of GUI oriented tools that weren't really do much aside from querying a database, I don't think that I've actually seen anything approaching a good code base that didn't have a moderate number of unit tests.

The real problem is with company culture... Most SE managers are friggin' clueless and have no idea how to run a software project. They've merely adopted the same work model as a McDonalds manager: everyone meets, you do this, you do that, I'm in charge, etc. Eventually these dinosaurs will become extinct, but until that time, we can always quit and work for better companies (like Google where unit testing is highly encouraged).


Certainly. It wasn't until a few years ago that Java replaced COBOL as the language with the largest existing code base; However, I don't think you need to limit unit tests to new code. If I'm given a project to maintain, I'll spend quite a bit of time going over the existing code and any 'smelly' code will be unit tested (and smelly code always has errors... always). If the managers or team lead is proactive, I'll get permission to take care of it then and there. If not, just improvise... "hey, what happens on your machine when you...". I've never worked for a team that didn't take action when a bunch of bugs have started to show up in the CR system (especially w/ external customers).

That was a good link Crashtech. From someone who doesn't really follow MS development, I found that to be very informative; However, I wouldn't get giddy just yet. The long-term goal may be to unify and simplify their development APIs, but as the article mentions, MS has always talked about doing it, and never actually done it. They have a habit of not delivering on this promise.

How does DirectX fit into their frameworks? Can you make use of the DirectX API from .NET now? Will you be able to use DirectX in with either code base in Win8?

I am on vacation, and it is awesome... but since I have a few minutes...

If you did your testing properly before hand, there is no reason to deploy the tests. No code is ever perfect and that includes tests. The point is, if you unit test before you release, there is no reason to send that code out with the application. I guess it can't hurt, but why? What you release should be lean and mean and clear of any extra stuff. It is too easy to accidentally include debugging specific stuff when you don't take it all out. Releasing it with the application only increases that risk.

Speed of the network or database is not my problem. DLL hell hasn't been a real problem in such a long time, that point is moot. You can't unit test for stupidity. You should be controlling the release processes anyway. Especially internally. How do you unit test for the correct database version anyway?

Yes.

Here is the main issue I have with unit testing... how do you unit test the unit tests? I know it is supposed to be a small enough unit to be easily verifiable...but it still seems a little like writing code to test code. You can still have issue? How common is it to have issue with unit tests?

I would challenge that. I am sure there are lots of above average companies with large, difficult to maintain code bases. It is hard to justify going back and spending extra time to fix things and add proper unit tests because it doesn't provide any forward velocity.

Agreed. Although I find it highly unlikely that things will change very quickly. Just based on what I have seen. It is a dream and a highly unlikely one at that.

Well good on you that you have been able to get the time. I have never been able to get the time to fix it properly and set it up to avoid issue in the future. The emphasis is always on getting things done even if they are less that correct.

Agreed, but I can see the point of not talking about it because of the whole Win FS issue... it is easier to not announce things until you are sure they are ready than talking about things and having to remove them.

I lol'd.



Still haven't seen the movie this clip came from... need to do that.

DLL Hell may not exist for you but it does exist elsewhere. What happens when you go work elsewhere and you run into that problem? Might as well unit test in advanced.

Just because you can't unit test for stupidity doesn't mean you can't use unit tests to validate non-stupidity.

In Rails, running rake db:migrate triggers a schema update. This update is then recorded in the database as schema_version. We could write corresponding unit tests that checks for the correct schema version, and if the environment fails to see that schema version, then you'll know that the environment is not setup correctly and you can address the problem in production - while deploying!



You don't. If the unit test is wrong, then you either scrap the test and rewrite it or you refactor it. However, the whole point of the unit test is to ensure that the code is right to begin with. In most cases, either 1. the requirements were wrong (because they changed) or 2. the person testing/using didn't understand what the requirements were. Unit testing's precursor is an understanding of what the client wants, the unit tests are just contracts (so to speak) that everything was done right. This is verified by the client. This is why Unit Testing is so integrated with Agile.



Good software teams should revisit old code and refactor. Especially if the life of the product is a long one. Good code is irreplaceable and often worth the time you put into it. Unit testing adds validation that this 'smelly code' is indeed right. Now, if the 'smelly code' looks smelly but meets requirements, maybe it can be refactored to make it less smelly (or smell clean) - but the validation that it meets functionality is found in the test, readability...well, that's through refactoring.



I operated like this until I realized that I could be doing more to produce better code. Honestly, I don't like this 'getting things done even if they are less than correct.' Do we want to conduct experiments where the data is 'less than correct'? I don't. I don't want my doctor to diagnose me with something if his philosophy of dianoses is 'less than correct' because he needs to churn out patients.

I don't disagree that things need to get done, my argument is how much should we get done in order that we can still do it correctly? I'm with DHH on this one: small tasks, iterative development (i.e., Agile) and small batches for release cycles is the way to go. It ensures that when we release something, we release a correct product rather than trying to churn out 100 things but it works half (or three quarters of the time).

You can't guarantee that the client machine is going to behave like your test machine(s). It isn't a perfect solution, but it gives you the assurance that at least your unit tests work on the client machine. Have a good vacation!


You can't test for stupidity, but that doesn't mean stupidity won't waste your time! You see quite a few issues with DLL hell on govt job sites, but it doesn't have to be external libraries -- You want to ensure that the client is using the correct version of your library, right?

From what I've seen, most databases still include the equivalent of a 'database -v', so you could check the version that way or by using internal system tables. What I really meant is to test for the correct schema version. Many defense companies 'deliver databases' which can become a sort of data DLL hell. Generally, in this case, you would check that the schema information version stored in the database is correct. If you were paranoid, you might also include checks to make sure the schema was as you expect (check for tables, then fields, then data types using the system tables).


Generally, if you're having trouble writing a unit test for a piece of code, there is a very high probability that the code in question is badly written. It needs to be refactored. I've never really had issues with unit tests, but I tend to write most of my code in a functional style, so I have small(ish) well-defined functions that are easily tested.

Regarding issues with unit test code...
true negative - The code is correct; The unit tests pass.
false negative - The unit tests pass, but the code isn't correct. You haven't done sufficient testing.
true positive - Here the unit tests fails on a piece of code with an error. Make sure that you don't have a false positive, then fix the code.
false positive - Usually this is easiest to correct (simply rewrite the unit test), but it might bring up some concern about your design (eg should I return null or an empty list).

IMHO, unit tests are invaluable. Sure, you can't test a UI very well with them, but you can find/fix many errors with them.


What are the options? To not fix things? To not be proactive?


Oh, don't get me wrong. I've also been bombarded with the "please figure out a quick fix" to someones craptastic software. I hate having to play the office politics games, but I'll play if that is what it takes...
"Uh, it'll take me longer to familiarize myself with the software than for the person who originally wrote it to fix it, so why don't you just have them fix it. From what I've seen, I can't believe this xxx works at all."
"If there was a quick fix, why hasn't someone already done this?"
"What do you mean that you don't actually want me to 'really fix' the software? You want me to leave it broken?"
etc. I actually hate playing games, but some places force it. Usually errors are clustered within software, so you can probably find enough additional errors to justify a proper fix.

Of course, you should probably be asking yourself the following question: why am I working for a company that won't allocate me enough time to properly fix their software? After all, you can't expect to get rich working for a companies that cannot afford to fix their software (w/ the exception of a few companies with monopoly power). Find a better job or ask for a transfer or something.