October 5, 2017 at 9:30 pm
Comments posted to this topic are about the item Why Don't You Unit Test Code?
October 6, 2017 at 2:07 am
My experience is that people in IT abdicate their power and authority. Many of the problems faced by IT are as a result of this.
Some of the things for which IT people ask permission are the equivalent of a garage mechanic asking your permission to reconnect the brakes of your car after a service.
Having the time to experiment with and learn new techniques is vitally important. You won't get that if you are always on the back foot and in fire fighting mode. I find that a refusal from management is rarely a hard NO, it is usually couched in terms that can be interpreted as no and usually an IT person will give up at this point.
In other words, put together a business plan for the introduction of unit tests. It helps if quantifying the problem of NOT having unit tests clearly places your bosses or your bosses bosses initiatives at risk.
Be honest but not too honest. There was a standing joke that if Atari sold KFC they would sell it as warm dead bird.
October 6, 2017 at 4:39 am
October 6, 2017 at 6:15 am
Sometimes it's the scope of the unit tests. There are some situations with complex UI, business rules and databases where it's difficult to build automated coverage beyond a certain percentage. Or the unit tests approach the complexity of the code under test and require unit tests of their own... It's turtles all the way down.
A recent project I did, spent 85% of the time creating and maintain unit tests, only to have a unique corner case not covered by tests come in from the field and require refactoring of the code and tests.
October 6, 2017 at 9:38 am
I really think most people just don't understand what the difference is between a unit test and an end to end test.
October 6, 2017 at 12:40 pm
ZZartin - Friday, October 6, 2017 9:38 AMI really think most people just don't understand what the difference is between a unit test and an end to end test.
I think this is true. They also don't understand how long manual testing can take. Or maybe they just like manual testing better.
I also think there's the issue that writing tests is an art, and trying to write tests that are self-contained and not too brittle takes practice. We also want to make sure we're not testing trivial items.
This isn't easy. I was hoping to have more responses.
October 7, 2017 at 11:54 am
David.Poole - Friday, October 6, 2017 2:07 AMMy experience is that people in IT abdicate their power and authority. Many of the problems faced by IT are as a result of this.Some of the things for which IT people ask permission are the equivalent of a garage mechanic asking your permission to reconnect the brakes of your car after a service.
Having the time to experiment with and learn new techniques is vitally important. You won't get that if you are always on the back foot and in fire fighting mode. I find that a refusal from management is rarely a hard NO, it is usually couched in terms that can be interpreted as no and usually an IT person will give up at this point.
- Quantify the problem that NOT having unit tests creates
- Clarify that the lack of tests will make the situation worse over time
- Quantify the benefit of having unit tests
- State the cost in time and money for introducing unit tests
- Identify the milestones that will demonstrate that the introduction of unit tests has lead to a benefit
- State the implementation plan
In other words, put together a business plan for the introduction of unit tests. It helps if quantifying the problem of NOT having unit tests clearly places your bosses or your bosses bosses initiatives at risk.
Be honest but not too honest. There was a standing joke that if Atari sold KFC they would sell it as warm dead bird.
As a part of this, someone should also "State the cost in time and money for NOT doing Unit Tests". It's a whole lot more substantial than most would think.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 7, 2017 at 3:07 pm
I'd be interested in the calculated number of test are after a thousand lines of code. I'm guess that is a big number.
October 8, 2017 at 1:37 am
Robert Sterbal-482516 - Saturday, October 7, 2017 3:07 PMI'd be interested in the calculated number of test are after a thousand lines of code. I'm guess that is a big number.
In my experience it lines of code to number of tests isn't an easily correlated thing. To give an example I built an ETL tool using Apache Spark and one of my team had invented a great way of testing it. We had our business analysts and testers capture the different input data sets and expected outputs in Git markdown tables held as files in the project. The project structure for where the markdown files resided mirrored the project structure of the ETL components. This meant that a few simple tests could test a huge number of transforms and scenarios.
Similarly the PyTest framework allows metadata to be supplied so again, one test run multiple times for different scenarios.
The need to test and to do so efficiently was a considerable factor in the design of the solution. The result is an ETL framework that we can extend amd refactor with confidence and with greater speed than we ever imagined. So much so that the biggest time consumer is now business people deciding what they want and fighting about priorities
October 8, 2017 at 6:43 am
David.Poole - Friday, October 6, 2017 2:07 AMMy experience is that people in IT abdicate their power and authority. Many of the problems faced by IT are as a result of this.
...
David has some great points.
I have seen coworkers approach testing and quality with a defeatism that is frankly unthinkable. If something is unacceptable, why do it?
With regards to E2E/integration tests vs unit tests, I have to push against this almost daily. Getting people to write *REAL* unit tests takes effort in challenging people to decompose problems into the small assumptions they make in operating systems.
The only valid reason I could see not to write unit tests would be that you expect to abandon your work, immediately.
October 9, 2017 at 12:16 am
I've been designing, writing, implementing and supporting complete accounting systems for 30 years. When I first started using SQL, I experimented a bit with some of its capabilities. I quickly discovered that, although there were a lot of things I could do in the DB, it made those functions invisible when looking at the program code. i.e. by looking at the program, I couldn't actually see what was being done with or to the data. Triggers are a great example. I found that intolerable and a huge opportunity for making major logic errors. Using SQL for things I prefer to handle in the program code is perhaps why some people are evangelists for writing "automated tests".
For my part, I choose to limit my use of SQL to mainly the CRUD operations, retrieving and sorting sets, simple joins and views, and using foreign keys for update and delete purposes where it makes sense. I do test the code, and while I have occasionally missed minor errors, they have never created a big problem and they have always been easily fixable.
I have never written tests and have never had an issue where I think having tests would have been worthwhile. The time and effort to write and maintain them would simply be a massive waste of time based on my experience.
Keeping things as simple as possible, without sacrificing functionality and ease of use for the user, is a central tenet of my programming philosophy. In my opinion, a lot of the "modern coding practices" (like testing) are mainly a result of poor programming methodologies, design choices and quality control. Of course, buzzwords and "the next big thing" also make a lot of money for the professional speakers, seminar producers and industry media.
In my situation, writing tests would cost a lot in productivity for a very negligible (if any) improvement in quality. Of course, YMMV.
October 9, 2017 at 6:45 am
Automated testing is GREAT for regression testing, especially in an OOP environment.
T/SQL isn't OOP, hasn't heard about OOP and frankly is anti-OOP. Militantly so.
Concerning the "invisible" aspects of SQL Server I must admit there is a huge grain of truth in this. However, used correctly SQL Server features actually eliminate the need for a lot of dynamic testing, and there are ways to step around the need for static tests.
Triggers, for example, are good for audit trails--and not much else, in my opinion. Even there you have to make very sure to document their presence, or you'll drive the next programmer nuts.
Referential integrity can introduce some head scratching, so it too should be well documented, through in practice it's a lot more visible than triggers. But RI slashes the need for entire categories of code, vastly simplifying code (and thus the need for tests).
The same with constraints. Also somewhat visible, and like RI seriously reduces the amount of code the programmer has to write--and thus the need for tests!
As a lone wolf I have an interesting perspective on application development, since I'm forced to straddle the border between the very different worlds of application side and database side. I don't have the luxury of a development team. I don't have the luxury of a QA department, or dedicated DBAs.
Therefore I'm pretty ruthless when it comes to time sinks. Automated testing is one of those. On the one hand they can save my butt when I do something stupid deep in the infrastructure layer on the application side--but given T/SQL's primitive coding and glacial interpreter I'm pretty limited when it comes to doing non-CRUD on the DB side. Which is actually a benefit as it minimizes the need to test. So...yay?
Testing is like comments. Everybody agrees its a good idea, but nobody (or almost nobody) really wants to do it!
October 9, 2017 at 6:45 am
blog 24112 - Monday, October 9, 2017 12:16 AMI've been designing, writing, implementing and supporting complete accounting systems for 30 years. When I first started using SQL, I experimented a bit with some of its capabilities. I quickly discovered that, although there were a lot of things I could do in the DB, it made those functions invisible when looking at the program code. i.e. by looking at the program, I couldn't actually see what was being done with or to the data. Triggers are a great example. I found that intolerable and a huge opportunity for making major logic errors. Using SQL for things I prefer to handle in the program code is perhaps why some people are evangelists for writing "automated tests".For my part, I choose to limit my use of SQL to mainly the CRUD operations, retrieving and sorting sets, simple joins and views, and using foreign keys for update and delete purposes where it makes sense. I do test the code, and while I have occasionally missed minor errors, they have never created a big problem and they have always been easily fixable.
I have never written tests and have never had an issue where I think having tests would have been worthwhile. The time and effort to write and maintain them would simply be a massive waste of time based on my experience.
Keeping things as simple as possible, without sacrificing functionality and ease of use for the user, is a central tenet of my programming philosophy. In my opinion, a lot of the "modern coding practices" (like testing) are mainly a result of poor programming methodologies, design choices and quality control. Of course, buzzwords and "the next big thing" also make a lot of money for the professional speakers, seminar producers and industry media.
In my situation, writing tests would cost a lot in productivity for a very negligible (if any) improvement in quality. Of course, YMMV.
And what happens when you hand your code off to me, who doesn't have the benefit of your programming experience and the wisdom to choose when to code simply and when not to? How will I make sure that everything still works the way it's supposed to? How will I reassure management?
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
October 9, 2017 at 9:18 am
blog 24112 - Monday, October 9, 2017 12:16 AMFor my part, I choose to limit my use of SQL to mainly the CRUD operations, retrieving and sorting sets, simple joins and views, and using foreign keys for update and delete purposes where it makes sense. I do test the code, and while I have occasionally missed minor errors, they have never created a big problem and they have always been easily fixable.I have never written tests and have never had an issue where I think having tests would have been worthwhile. The time and effort to write and maintain them would simply be a massive waste of time based on my experience.
Keeping things as simple as possible, without sacrificing functionality and ease of use for the user, is a central tenet of my programming philosophy. In my opinion, a lot of the "modern coding practices" (like testing) are mainly a result of poor programming methodologies, design choices and quality control. Of course, buzzwords and "the next big thing" also make a lot of money for the professional speakers, seminar producers and industry media.
In my situation, writing tests would cost a lot in productivity for a very negligible (if any) improvement in quality. Of course, YMMV.
In your case, I'd agree. I don't write tests for inserts, or simple selects. Only when there's some business logic, mostly because I need to document the business logic as it can change, I may have misunderstood it, or there might have been incorrectly given to me. But core SQL Server/RDBMS stuff? I wouldn't test that.
Keeping things simple is important. I'd say that the places where you do need to write tests, why not formalize them? It really doesn't take longer, especially if you need to setup up an environment and run them a few times as you work out the logic.
I certainly wouldn't aim to test everything, or not necessarily a large part of the system.
October 9, 2017 at 11:09 am
It's hell on earth Inheriting someone else's code, or more likely a team of people's code where the word "team" is stretching it a bit.
I think the visibility aspect is overstated. There's an article about refactoring code which highlights the case where fine grain
Code loses the context of whole app. Code refactored down to its simplest level is easy to change and maintain due to the clarity of each part but trying to get a feel of the whole is nye on impossible.
Ive had the argument about what lives in the DB and what doesn't so many times. If poor data quality is the result then the decision was
Wrong. "Business logic" is too broad and vague to be able to make a definitive statement about it's location. People who are comfortable with both code and DB won't have as many problems finding which tool has been applied to which problem.
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply