Tag Info

Hot answers tagged

30

As with many things, unit testing is best supported at the library level, not the language level. In particular, C# has numerous Unit Testing libraries available, as well as things that are native to the .NET Framework like Microsoft.VisualStudio.TestTools.UnitTesting. Each Unit Testing library has a somewhat different testing philosophy and syntax. All ...


15

There's lots of reasons. Eric Lippert has stated many times that the reason feature X isn't in C# is because it's just not in their budget. Language designers don't have an infinite amount of time nor money to implement things, and each new feature has maintenance costs associated with it. Keeping the language as small as possible isn't just easier for the ...


13

Because testing, and particularly test-driven development, is a deeply counter-intuitive phenomenon. Almost every programmer begins their career believing they are much better at managing complexity than they actually are. The fact that even the greatest programmer cannot write large and complex programs without severe errors unless they use lots of ...


9

One quite intuitive way to handle this is to code a truth table into your test so you have something like: //last in tuple is expected result, rest are inputs test date = new List<Tuple<bool,bool,bool,bool,string>>() { {true,true,true,true,"foo"} {true,true,true,false,"bar"} etc... } i.e. a data driven test. For big table you can move ...


8

Your mistake is to assume that the code is short. The fact that it's one-liner doesn't mean it's simple to test, to debug and to maintain. If I had to maintain this code, I would have WTFed quite a lot about people who like writing cryptic, condensed code (also, I hope your a, b etc. variables are just for an example, and in real life, you use more ...


7

You're making a big mistake when you put assumptions into your unit tests about how the unit is implemented. Consider what would happen were the implementation of OrderService to change so that it no longer used DateCalculator (or, more generally, if you wanted to test a different implementation with the same unit tests). Your unit tests for OrderService ...


7

If you don't test a User Story (US) and verify that the acceptance criteria are met this story is not done. If its not done this US goes to the next sprint of course. And if all your US are in this state you sprint has ended with no value added to the project. From the client point of view I cannot distinguish this from the entire development team going on ...


6

A lot of languages have support for testing. C's asserts are tests that the program can fail. That's where most languages stop, but Eiffel and more recently Ada 2012 have preinvariants (things the arguments to a function must pass) and postinvariants (things the output of a function must pass), with Ada offering the ability to reference the initial arguments ...


6

One option is to use an in-memory testing database such as H2; it tends to be about about 10x faster than a standard disk-using database, and with lower startup/teardown times. Whether it will help does largely depend on whether the JPA issues you are having are general enough that they will still fail on different database. Not much point running tests ...


5

Unit tests are code as everything else. So if you merge your code, and your unit tests depend on the version or revision of the non-testing code (which is normally the case), you should always merge your tests together with everything else. This includes the resolving of any merge conflicts, if they occur. If the merge conflicts of your test suite are not ...


4

I think that there is a common misconception as to what BDD means, that BDD means that we are now writing our tests using tools like Cucumber, SpecFlow, etc instead of traditional unit tests. That is not the case. BDD is more a way of thinking that moves our focus in the tests from the technical aspects to the more business oriented aspects. Also see this ...


4

Is it appropriate to store these bitmaps as resources Well, whatever will work for you is appropriate, isn't it? Your unit tests should run quick, be functional, should be easy to maintain and to extend, and if they fail, they should make root cause analysis easier for you. "quick" can be fulfilled by using very small bitmaps "functional": to include ...


3

The essential problem is that you have programmers who code but don't test and testers who test but not code. Solve that problem and you will not have this problem, and an arguably more efficient team. One way that worked for me in the past was to suggest coders and testers to pair on stories with the explicit task of delivering a fully tested story. ...


3

if all or most of the coding is not done until the end of the sprint? Why is it not finishing sooner? This key limitation is the source of your troubles, and I've seen two approaches be successful. One fits well into the agile approach (but not other common practices) and the other taints agile a bit (but is more common). The first is that you don't ...


3

The actual role of your QA is close to acceptance testing. I would imagine this to be done by a separate team, which acts more as product owner rather than a part of the development team. Example: during a sprint, you need to add a feature which enables to filter search results by different criteria. You already have your search mechanism implemented, but ...


2

First of all this should be tested by system/acceptance tests that cover what ever feature needs this class for unit tests I'd say the answer is mostly no, there is nothing useful to test here, the only time I would unit test is if it was more effort to justify why I'm not testing this class than to test it (sometimes the case with safety related stuff)


2

It appears to me that you have a fundamental problem with your components. C should do what C needs to do, and be tested, documented and designed to do just that. When you have a situation where C is designed to "do what B wants" you have an abusive relationship, one that becomes very clear when A arrives and wants C to do something slightly different. ...


2

I would argue that you have missed the addition of some of the necessary features because they weren't being highlighted as for unit testing. For example, unit testing in C# is mainly driven by using attributes. The Custom Attributes feature provides a rich extension mechanism that allows frameworks like NUnit to iterate and compete, with things like ...


2

Some proponents of strongly typed functional languages would argue that these language features reduce or eliminate the need for unit tests. Two, imho, good example of this for this is from F# for Fun and Profit here and here Personally, I am still believe in the value of unit tests, but there are some valid points. E.g. if an illegal state is ...


2

Databases can be very easy to unit test - you need stored procedures and transactions. This what Microsoft says about Database unit testing. You can also run unit tests against a database, writing your tests in Java or C# by setting up a DB connection, beginning a transaction, write whatever data you want to use for the test to the DB, run the tests and ...


2

Ideally you should change your design a little bit and decouple OrderService from DateCalculator.CalculateLeadTime by using dependency injection: class OrderService { Func<DateTime,WidgetOrder> _calculateLeadTime; public OrderService(Func<DateTime,WidgetOrder> calculateLeadTime) { _calculateLeadTime=calculateLeadTime; } ...


1

TLDR: It's a bad idea (see below to read why). First, I wanted to address this: I understand this goes against the principle of TDD, but I don't think anyone ever proved that doing TDD is better over first creating code and then immediatly therafter the tests. This may even be adapted to be fit into TDD, but that is not my current goal. TDD is better ...


1

It's all just software, so given enough effort it's possible ;-). In a language which supports a decent way of doing code analysis it should be feasible too. As for the usefulness, I think it some automation around unit testing is useful to a certain level, depending on how it's implemented. You need to be clear about where you want to go in advance, and ...



Only top voted, non community-wiki answers of a minimum length are eligible