Our new Indie Games subforum is now open for business in G&T. Go and check it out, you might land a code for a free game. If you're developing an indie game and want to post about it,
follow these directions. If you don't, he'll break your legs! Hahaha! Seriously though.
Our rules have been updated and given
their own forum. Go and look at them! They are nice, and there may be new ones that you didn't know about! Hooray for rules! Hooray for The System! Hooray for Conforming!
SELECT * FROM posts WHERE tid = 'PA PROGRAMMING THREAD'
Posts
That in itself isn't that big of a deal. He doesn't have much experience with Django and this was a good way for him to learn some of the intricacies of Django's orm. But that I said this was going to break and to watch out for that situation, attribute, and methods that touch that attribute specifically, provided links to Django's documentation on how those things work, provided links to documentation on how our implementation behaves and uses those things, provided tests to do after making changes to make sure it all still worked, and offered a couple different suggestions on how to fix it if it broke in the way I expected and then all of that was apparently ignored, including testing, annoys the hell out of me. Then proceeding to "fix" it while still obviously not understanding what was broken or why it was broken after I said "This is broken, let's wait to fix it after we discuss it and plan the fix because there are a couple options with different tradeoffs" is doubly frustrating.
Fortunately it turns out the "strange idea" he implemented was basically what I told him he'd probably have to do in the first place.
I really want to start a "peer recommendation" website where your peers can weigh in and give you praise or list off what your responsibilities were so you can use it in case of hostile feelings when leaving a company, especially in situations like that.
I chose not to go this route because the gem is a couple of versions behind (both this and jquery-rails are). I'd rather just manually feed them in to the asset pipeline (which I did).
Fair enough!
I want to get in on the PADev.net blog train. I've got some articles in mind about ATDD/TDD with Ruby.
Yeah, Sublime is amazing. It uses TextMate color themes too, so if you're like me and like a particular color theme that TM has, Sublime can use it. (In my case, it's Grandson of Obsidian, which was forked from Son of Obsidian for Visual Studio, which was forked from Obsidian for Eclipse).
TDD is my biggest short coming with rails. Actually, unit tests period, are just a short coming for me. I tend to find them so incredibly cumbersome and tedious to maintain. I start out with great intentions, but once most of my projects reach that middle level of maturity, I've just given up.
All the examples I've seen have the whole 'red-green-refactor' schtick and apply it to things that are fairly simple to get working anyway. Not exactly enticing me to change my workflow. But, since it's a 'thing', I should probably learn how to do it.
Stack Exchange | http://www.mpdevblog.blogspot.com
I have several issues with this. First it assumes you know enough about your requirements to write good tests, which is rarely the case in a lot of environments. Bad requirements are just a fact of life in development. Second, it assumes you understand exactly how your going to design the code unit that's going to be tested, because you have to design tests that harness to that design.
Exactly.
I'm much more of a small prototype guy. I need a feature? I make a small standalone version and test it. That allows me to play with it beyond staccato pass/fail conditions. Once it works, I incorporate it into the rest of the project and test some more. Rinse and repeat, refactoring where necessary.
Then again, I'm also someone who thinks the terminology associated with scrum is painfully lame, and that a lot of it comes across like some bored middle management person's wet dream. I think I have some sort of hangup about codifying the development process in general, outside of using source control. A lot of it seems either obvious or unnecessary, and largely a waste of time. But, I've never had to work in a team before, so I'm definitely not getting a full picture (yay working for myself/freelancing!).
Stack Exchange | http://www.mpdevblog.blogspot.com
The only serious downside I have with this is that once you've got working code, sometimes it's hard to convince the business/product owner that it's still really important to write the unit tests rather than moving on to the next bit of functionality.
The PhalLounge :: Chat board for Phalla discussion and Secret Santas :: PhallAX 2013
Critical Failures IRC! :: #CriticalFailures and #mafia on irc.slashnet.org
Foxpro?
I'm currently writing code (in pickBASIC) to generate PDFs. So there is my special hell for the day
Diablo 3 Profile
So we have a templated unit test framework we developed ad-hoc while writing some heavily templated code, and it is pretty amazing. We can write up a series of templated unit tests, and then dispatch a collection of objects to test with them by changing the tag we use when running the test.
namespace { template<typename VectorType> void TestAbs(VectorType negative, VectorType positive) { TEST_ASSERT(test_equal(proj::math::Abs(positive), positive), "Abs failed."); TEST_ASSERT(test_equal(proj::math::Abs(negative), positive), "Abs failed."); } struct TestSignFunctor { template <typename T> void operator()(const T&) const { typedef project::VectorTraits<T> Traits; T negative, positive; for (int index = 0; index < Traits::NUM_COMPONENTS; index++) { AbsInput(Traits::GetComponent(negative, index), Traits::GetComponent(positive, index), index); } TestAbs(negative, positive); } }; void TestSign() { project::Testing::TryAllTypes(TestSignFunctor()); } } // anonymous namespace int UnitTestMathSign(int, char *[]) { return project::Testing::Run(TestSign); }The benefit is that when we add a numeric class in this example we can see exactly when it starts failing certain tests fairly automatically.
Real world examples that are more interesting than pagination or a shopping cart.
A discussion on how developers actually approach writing their tests (especially when writing the initial tests for a project/module).
Stack Exchange | http://www.mpdevblog.blogspot.com
Hnnnggg I don't wanna be trained in VB.NET, I wanna learn C#.
I love how Vanilla decided to include a D: in your code. Fitting.
Right about the time in typing that line my face does it too
$(document).ready(function() { $.validator.addMethod("handle", function(value, element, param) { return this.optional(element) || /^[\w\d]*$/.test(value); }); $("a[rel=popover]") .popover({ offset: 10, placement: 'top', template: '<div class="popover"><div class="arrow error"></div><div class="popover-inner error"><h4 class="popover-title error"></h3><div class="popover-content"><p></p></div></div></div>' }) .click(function(e) { e.preventDefault() }); var validator = $("#new_user").validate({ debug: true, rules: { "user[email]": { required: true, email: true, remote: '/validate/email' }, "user[handle]": { required: true, minlength: 3, maxlength: 15, handle: true, remote: '/validate/handle' }, "user[password]": { required: true, minlength: 6 }, "user[password_confirmation]": { required: true, equalTo: "#user_password" } }, messages: { "user[email]": { remote: 'E-mail address is already in use by another account.' }, "user[handle]": { handle: 'Handles may only contain letters and numbers.', remote: 'Handle is already in use by someone else.' } }, errorPlacement: function(errors, element) { var errorList = ''; for (var i = 0; i < errors.length; i++) { var icon = $('#' + errors[i].htmlFor + '_icon'); icon.removeClass('icon-ok'); icon.addClass('icon-remove'); errorList += '<li>' + errors[i].innerText + '</li>'; }; if(errorList.length > 0) { var popover = $('#' + element[0].id + '_popover'); popover.attr('data-content', '<ul>' + errorList + '</ul>'); popover.popover('enable'); } $('#submit_user').addClass('disabled'); }, success: function(labels) { for (var i = 0; i < labels.length; i++) { var icon = $('#' + labels[i].htmlFor + '_icon'); icon.removeClass('icon-remove'); icon.addClass('icon-ok'); var popover = $('#' + labels[i].htmlFor + '_popover'); popover.popover('disable').popover('hide'); } if(validator.checkForm()) { $('#submit_user').removeClass('disabled'); } } }); $("#new_user").valid(); });e: Updated the code, added a regex custom validator and some messages to the remote calls.
The most important part of TDD for me is that it forces me to focus on the actual requirements, rather than the implementation. If you don't know the requirements (or can't at least guess at them), then how are you supposed to know what the system should do? Even if the requirements are vague, or haven't been fully fleshed out, you still want the system to behave in a well-defined way, otherwise, what the hell are you even doing? Requirements change a lot, but it's almost never a big deal to change the tests, unless your code is so highly coupled that a single change breaks a significant portion of your tests.
The red-refactor-until-green loop is pretty cool, but the examples out there take this way overboard for what you will do most days. I've never attempted to run a unit test if I have a compilation error. I never run a unit test on a piece of code that I know isn't implemented yet (returns null or throws some kind of NotYetImplementedException). Just write your tests, write your code, and start the red-red-green loop from that point.
Also, find a good mocking framework. It's virtually required for testing anything remotely complicated. I've used a bunch of frameworks for Java, but Mockito is my favorite. I've used Moq for C# which was also very good (lambdas make setting up mocks very easy).
If you find your code has a bunch of conditionals which makes it hard to test, then you're probably testing too much. Break that method into smaller pieces. This sometimes forces you to break encapsulation, but in my opinion the trade-off is almost always worth it.
(Not saying you were doing that Halibut, I'm just soap boxing it up)
I will say though, that you should come up with a solution for verifying that your code does what you intend it to do. No one is perfect, and you can't expect (or be expected) to perfectly translate a requirement (or idea, or whatever) into code the first time out. Especially on bigger projects.
I guess the arguement against that is this. Manual testing is slow and monotonous, and you're not always going to remember to go back and retest everything every time you make a change, even if you know exactly what the change impacts. Take for instance the project I'm doing right now, a weekly workout scheduler for a small gym. Right now, I have about 139 tests, which include Model and Controller Unit Tests and Integration tests that drive the User Flows. It takes around 27 seconds to test all those things (which is faster than I could manually end-to-end test one flow), and it takes less time to add a new test than it does to set up debugging or other methods of manually looking at the objects. I've got a gem (guard-rspec) that runs the relevant tests every time I make a change (so it runs the integration tests when I change the view, the model tests when I change the model, etc) and sends me an alert of the results, so I don't even need to manually kick them off or pay that much attention to them. If more than one test breaks when I do something, I've got a good idea that I did the wrong thing.