Outrospective.org

http://www.csharp-station.com/Tutorials/AdoDotNet/Lesson01.aspx

Today I was looking for a good tutorial for using SQL parameters rather than build strings on the fly. We ran into STAKS 😉 of problems trying to convert different datatypes into a correct SQL string.

That said the linked tutorial provides a great intro to parameterised queries and doesnt try to get you to do more hoops than you need. (see Lesson 4 I think)

My recent Uni project team faced staks of problems recently when it came to synchronising and developing different areas of our system.

There were a lot of lessons learnt by all, I’d like to put down here my lessons I received:

– Make your design clear at the beginning. Ensure that you have Class and Sequence diagrams that tell you what needs to be written by you and tell others in your team how they can interface with your work. A method signature in a class diagram represents a contract to other developers.
– Even if you haven’t implemented all the methods you were assigned to write, others waiting on your work shall be able to use your design and mock these objects in there own tests.
– Errors will always occur. There will be errors in logic, errors in syntax and errors in integration. Usually you can pick up errors in syntax before you submit your code. Always expect errors in integration but provided that you right to the interface agreed on in your design and only make changes to those interfaces when agreed by all.
– Make a time to discuss far-reaching changes that affect the whole project and architecture of the system. Don’t implement changes you see fit without advising your team in advance of those changes, and then allow time to discuss the changes before implementing them yourself.
– Don’t change other people’s projects. If you need to change code that interfaces with yours, pair with the programmer that wrote the code.
– If using a version control repository, commit often to keep changes up to date.
– Likewise, don’t check in code modified by someone else as your own.
– If someone discards the above without good reason (a deadline is an excuse, not a reason – one that I’ve shamefully used in the past) and provides code to the repository or rest of the team, discard and rollback to the previous version until changes meet standards and are agreed on by all the team.
– Meet as often as possible and provide updates about what troubles you.
– Document often, give your objects, methods and variables meaningful names.
– Get everyone involved on all decisions, ensure no one is left out. Its likely someone will stay in the shadows if you treat them that way and they can be the ones with the best opinions and critique. They will also not state their objections which is important because they’ll loose faith in the project and when it comes time to deliver, may not come through, simply because they can’t find and are not motivated to complete a task they dont believe in.

On the Thought: How do you tell someone their code/design is bad?

I’m sure as a Junior Developer there have been many a time people have wanted to tell me this. Some have and I’m all the more better for it. Thanks.

The actual article though links to a discussion about OO patterns and a useful discussion about how to write your classes to make them more testable.

Ok, so the time has come to write tests. You want to conform to Test Driven Development. You’ve been taught the power of Design by Contract, but abysmally, you learn that apart from Eiffel with its postconditions, preconditions and invariants, you are going to have to setup your own test fixture around your C#/Java code that does similar things. (see Design by Contract Framework).

For public and protected methods, it is easy to access those calls and write unit tests around them, but private methods are well, private. You could place assertions at the start of your method (emulate preconditions) and exception throwing at the end (emulate postconditions) in those private methods to implement pre and post conditions but your fine grained unit now becomes a little bloated and hard to read and you still lack a test fixture that will run that private method on demand and let you know if the outside world has changed its mojo.

I believe that this comes down to design. How you design your classes, which methods take what responsibilities and delegate to other classes. Some clever cookies come up with even more cleverer designs that reduce code and provide hooks into your methods to test them from the outside looking in. The new guy at work keeps telling me about the patterns he implements, his class structure because of those patterns and how all his code can be easily tested. I watch with interest, how he can pass the model around freely and decouple the functions and indeed learn that:
Good Design makes for Greater Effeciency, and
Good Design makes for Easier Testing which makes for Greater Efficiency. (and so on and so forth!)

See here for an example of what I think he is referring to.

So without being a Design Pattern ninja, I’m left to trawl the net for the basics (dont worry, these design patterns that allow for easier testing wont be left alone for long, believe you me), but there are some alternate means of writing unit tests for private methods.

With this approach comes the debate about whether you should actually write (or try to) Unit Tests for private methods. Should your self contained unit simply be tested by its public interface, or should you go hardcore Design By Contract and test each function to its contract; testing it to the letter of the “coding standard” law in your development house of jurisdiction. (Apart from being a nerd, I also am talented in the art of dorky jokes)

One thing I have learnt is that if you haven’t designed your class correctly, you will find it difficult to write unit tests to begin with because they will be hedging in the direction of integration tests (as in too much, too many hands in one spot). If your tests are long, perhaps the functionality should be broken down and hidden (too many methods not doing enough, work shared unevenly, meaning more setup code to test some methods)

Your private methods should be small helpers and as time goes by, perhaps, and this is only my opinion with limited pattern knowledge, refactored so that they are pushing the work out to a factory or other builder and now you are just testing the building of a correct object that functions as expected, rather than an object being correct overall.

To summarise the approaches of unit testing private methods:
1) Change the access modifiers to protected and build test classes that work in the same package as the methods. This kinda stuffs up your whole class
2) Use reflection to find and run those methods. Bad thing is if you refactor, you have to change the strings that are the method names manually.
3) Don’t test your private methods. Test the public ones that call said method, ensuring as best as possible to create all cases against the private ones.
4) Redesign; a new design pattern, a new approach to feed your supporting objects in.

So there are a plethora of links and resources I want to share with my Firefox bursting at the seams with tabs, so lets go:

– How to Test Private and Protected methods in .NET provides a quick overview about the pro’s and con’s of testing private methods and delves into the methods to circumvent this protection. It waives the flag for using reflection of your private methods to test, but this comes at a cost of any renaming refactor requires a code change to the string by which you Emit the desired private method to test.

– For Java affaciodos, Testing Private Methods with JUnit and SuiteRunner provides the Java perspective and the same techniques that can be applied to .NET can be applied to Java also. Again reflection is the flag most waved but provides a balanced look at the others. Bruce Eckel (of Thinking In Java fame) also plugs this site here (to which I was led to his own site and got distracted about his pages about the greedy book publishing industry)

– If you are lucky enough to have the Visual Studio Team System edition for Testers, it appears to do all the hard reflection work of testing a private method for you automatically, but does come with the same creveat of reflection

If the signature for a private method changes, you must update the unit test that exercises that private method. For more information, see How to: Regenerate Private Accessors.

– This link is an against for the testing private methods debate.

– This is another against which mentions C++ friends and the more techy details of assemblies and changing the accessor from private to protected internal, so I thought I’d include it here (i wish i had friends in C# right now, hehe)

– And here is a well written for unit tests on private methods.

– Apparently NUnit 2.4 will provide a Framework Extension to test private methods (http://nunit.com/blogs/?p=25)