What open-source codebases have you used to learn refactoring, written in either java or C# ? One requirement is good unit tests.
A code that accompanies my "Professional Refactoring in C# ans ASP .NET" book includes a sample application that is refactored throughout the book and you can observe how it evolves. You can download the sample code here. Note: does not include unit tests.
Related
I am beginning to adopt Test Driven Design (TDD) behaviors and workflow for my iOS development projects. There is at least one impediment though in the context of legacy software. I will often have to add features to a pre-existing code base that I am new to. I will typically want to refactor at the beginning of working with the code base which will often have no tests available to ensure that my refactor-ings are not altering code functionality or worse, adding bugs.
My question is how do TDD folks bootstrap the whole process when the code is not written from scratch but rather legacy code that they are brought in to work on?
Thanks,
Doug
UPDATE
For a concrete example, I am using the example from Martin Fowler's Refactoring re-coded in Objective-C as a training device for TDD (and AppCode) >>
I built the code from tests. I found I needed to add instance variables to the Customer class to ensure I didn't screw up the cost calculations in the statement method as I grew the code. This is the fundamental issue I need insight into.
To begin with, if you don't understand the legacy code you're working with, you need to fix that before you do things which you're concerned may change behavior.
In your situation, after understanding the legacy code, I would write tests that will run against that legacy code. Once you're satisfied that these tests function as you expect, you're in a much better position to test your refactored code to ensure it functions as the old code did.
our dev team is currently using asp.net 2.0 and after a lot of browsing and cross site referencing i found that the new in thing is the asp.net MVC but found that there's a few things that it can't do such as support asp.net controls, view state.
i'm not sure what are the other limitation besides the total change of paradigm where each page will now link to the controller which will be linked to a certain view. so in order to make the learning curve to be less steep, i wanted to pick up on MVP first as i think by just being able to take out the application and domain layer out and make them testable is already a big help to our total process without being too much of a hassle.
after more browsing around, i find that the ndoc is a bit outdated now and is being replaced by sandcastle which has an additional add in call docproject so that should covers the auto generation of the documentation in the codes very well.
and to handle the acceptance test, i find this tool call fitnesse which is based on FIT which should helps.
so being totally new to all of this, i'm wondering if this is a good process overall to have this tool in to cover our team's development process. and if there's other sample/resources/framework out there which covers all of these steps and does a better job than trying to piece in the gap by using several tools, i.e. a framework?
basically my question is is my
overall process above well covered
by the tools that i've researched?
and is there a better way to do the
asp.net tdd + auto doc generation +
acceptance testing?
any advice/feedback is appreciated.
thanks!! :)
Yes, ASP.NET MVC with NUnit and FitNesse are reasonable choices for an 'agile' approach. Just not sure where auto-doc generation fits into this. Will anyone read this generated documentation or will they just look at the code? If you haven't read it yet, get Robert Martin's 'Clean Code' for some good tips on how to make code maintainable and understandable without lots of comments and generated documents.
I've recently have started writing unit tests for PL/SQL code in Ruby.
Are there any other language combinations where you write your code and unit tests in two completely different languages?
A common combination is code in Java and tests in Groovy. Which is particular interesting because Groovy is built "on top of" Java, for example Groovy even uses the same testing framework as Java.
We write groovy tests for our Java application. Mainly cause we want to learn and experience other programming languages.
I've seen unit tests written in Ruby for a C library wrapped with swig.
The main advantage compared to the same unit tests written in C being the interactive Rub interpreter (irb) that permits to do exploratory testing.
Few years ago we used Python to test C++ code, using Boost to export classes.
Unit tests were written in python.
The interesting part of this architecture is that we were able to access to living objects from a python console, because the logic was expressed in python, C++ was used to build low level classes.
If you're adding a new language to an existing project it's perfectly reasonable to do functional/acceptance tests in the existing language.
When we first adopted Ruby on Rails, we still used JUnit and HTMLUnit to test the web front-end and did assertions directly against the database backend.
If you're still learning how to use a new piece of infrastructure it makes sense to keep using a testing method that you can trust whilst you do the transition.
We did eventually start using test/unit in ruby, and selenium - but it was useful to a transition period where we relied on our existing Java-based tests...
I apologize. This is part rant, part question.
For the rant: Dear MS developers who post MVC projects on CodePlex and dedicate their sites to MVC with TDD: I love to learn from you and thanks for the examples, but not everyone has Pro. I'm sick of not being able to load the test project portion of these things because use Standard, which more than covers most needs [with Nunit]. It's annoying.
Now, for the question. :-)
Is there a tool out there to convert these unit test projects to a proj file Studio Standard can open so I can at least compile and view the code?
--
P.S. Dear Microsoft: Enough with not including unit testing with all versions of Studio already. It's silly. Testing is not just an "enterprise" or "pro" feature.
In most cases, switching between test frameworks is just a case of search/replace. If the csproj doesn't load, just create a new project file and drag the code files in and fix them afterwards (along with the references). TestDriven.NET, for example (or NUnit console) are perfectly happy with just a dll/exe as the test project.
Maybe a pain, but not necessarily a huge problem.
If you want to use NUnit with MVC, there are brief instructions here and here - I don't know (haven't tested) whether they apply to Standard.
Environment: (C# WinForms application in Visual Studio Professional 2008)
I've been digging around a little for guidance on NUnit best practices. As a solo programmer working in a relatively isolated environment I'm hoping that collective wisdom here can help me.
Scott White has a few good starting points here but I'm not sure I totally agree with everything he's said -- particularly point 2. My instincts tell me that the closer a test is to the code being tested the more likely you are to get complete test coverage. In the comments to Scott's blog posting is a remark that just testing the public interface is considered best practice by some, but I would argue the test framework is not a typical class consumer.
What can you recommend as best practices for NUnit?
If by point 2, you mean the "bin folder per solution" -- I can see your point. Personally, I would simply add the reference to each test project. If, on the other hand, you really mean (1b) "don't put your tests in the same assembly as your code" I heartily agree with him and disagree with you. Your tests should be distinct from your production code in order to enhance code clarity and organization. Keeping your test classes separate helps the next programmer understand it more easily. If you need access to internals in your tests -- and you might since internal methods are "public" to the assembly, you can use the InternalsVisibleTo construct in the Assembly.cs file.
I, too, would recommend that, in general, it is sufficient to unit test only the public interface of the code. Done properly (using TDD), the private methods of your code will simply be refactorings of previous public code and will have sufficient test coverage through the public methods. Of course, this is a guideline not a law so there will be times that you might want to test a private method. In those instances, you can create an accessor and use reflection to invoke the private method.
Another recommendation that I would make is to use unit testing and code coverage in tandem. Code coverage can be a useful heuristic to identify when you need more tests. Lack of coverage should be used as a guide to indicate where more testing may be needed. This isn't to say that you need 100% coverage -- some code may be simple enough not to warrant a unit test (automatic properties, for instance) and they may not be touched by your existing tests.
There were a couple of issues that I had with the article. Probably the biggest is the lack of abstraction away from the database for unit tests. There probably are some integration tests that need to go against the db -- perhaps when testing trigger or constraint functionality if you can't convince yourself of their correctness otherwise. In general, though, I'm of the opinion that you should implement your data access as interfaces, then mock out the actual implementations in your unit tests so that there is no need to actually connect to the database. I find that my tests run faster, and thus I run them more often when I do this. Building up a "fake" database interface might take a little while but can be reused as long as you stick with the same design pattern for your data access.
Lastly, I would recommend using nUnit with TestDriven.Net - a very useful plugin whether you're doing nUnit or MSTest. Makes it very handy to run or debug tests with a right-click context menu.
My instincts tell me that the closer a
test is to the code being tested the
more likely you are to get complete
test coverage. In the comments to
Scott's blog posting is a remark that
just testing the public interface is
considered best practice by some, but
I would argue the test framework is
not a typical class consumer.
If your code cannot be tested using only public entry points, then you have a design problem. You should read more about TDD and SOLID principles (especially single responsibility principle and dependency inversion). Then you will understand that following TDD approach will help you write more testable, flexible and maintainable code, without the need for using such "hacks" as testing classes' private parts.
I also highly recommend reading Google's guide to testability by Miško Hevery, it has plenty of code samples which cover these topics.
I'm in a fairly similar situation and this question describes what I do keep-your-source-close-and-your-unit-tests-closer. There weren't too many others enamoured with my approach but it works perfectly for me.