What to do when you can't write unit tests, but you want to ship a reliable product?

What are the strategies that come to your mind when you need to develop & ship a product really fast and you can't afford to spend time on writing unit tests? I know unit tests are important, but I also feel you need to have sufficient amount of time to write tests. What do you do to improve the reliability of code/product in this case?

Write your software as modular as possible, that way when you make changes, you only affect one part of the system. So if you need to be able to have users log in, have an Account module handling password resets, authentication, authorisation, etc. If you need Email, build an email module that handles all email in the system, etc.

Further, build APIs for everything and do everything via APIs - I usually build RESTful JSON APIs with Create, Read, Update, Delete, List and Search.

Java uses UUID version 4 which has 122 bits of randomness built into the 128 bit UUID which is not guessable, multiply the 122 bits by 4 since I'm concatenating them + stripping dashes and then also take into account that if you send an incorrect UUID for a certain username, all UUIDs for that username is invalidated (although I only allow one UUID per username to be active at any time), if you try multiple times, your IP gets blocked.

So in practice, if you guess the UUID incorrectly the first time, you invalidate all other valid UUIDs in any case, if you try a second and third time or tamper in any way with some of the other data in the cookie (you won't have any success in any case since the UUID has already been invalidated during the first attempt), your IP gets blacklisted and you will simply get the same response (login: true, access: false) over and over until your IP is removed from the blacklist again.

All of this is going via SSL, so only you, once you have logged in, will be able to see the UUID, any attempt to tamper with the UUID blocks your IP and any attempt to guess someone's UUID will log them out invalidating the UUID followed by blacklisting your IP if you continue trying. Guessing the concatenated UUID is like guessing a 64 character password which is randomised by Java every time you log in of which you only have one shot.

To me the Java implementation sounds pretty secure, I can't speak for other languages though. Have a look here, as you can see in the source code snippet, Java uses SecureRandom to generate the random bits: stackoverflow.com/questions/7532807/are-java-rand…

Maybe I'll start a topic on GUID security, then we can peek into which languages do it securely and which ones don't.

GUID's aren't cryptographicly secure and shouldn't be used as security tokens. security.stackexchange.com/questions/890/are-guid…

I send a GUIDx4 tokens (4 GUIDs concatenated together) with every request automatically - the GUID token is generated once you login and kept in a secure-http-only cookie. So every request to the API automatically includes the cookie with the token and then inside the API logic I simply extract the token, check if that token is valid against a Redis database, if not, reject the request and send back an access denied (in which case the frontend will popup a login dialog).

Since the Cookie is set on the API's domain instead of the frontend domain as well as HTTP-only flags, JavaScript can't tamper with the Cookie or even read it, once you do an AJAX post, the browser automatically includes it as part of the post, so the browser itself is the only thing that can read the cookie. Without the cookie containing a valid GUID / token, you can't interact with the API, it will just respond with {access: false, login: true}

I typically have to implement CORS on the API as my AJAX requests are coming from a different domain than the API is sitting, see this post for more info on the security aspects: security.stackexchange.com/questions/84860/how-to…

I think it's totally valid to be in a stage where you have to move fast, as long as you understand the size of the technical debt that you are incurring. Don't ignore tests blindingly though - there are definitely pieces of code where writing tests will actually help you write faster (TDD or not).

Writing code that is easy to test will improve reliability even without actually writing tests, as the principles that make code testable are the same for writing good code (very modular, declare dependencies, single responsibility etc.). So I would suggest doing that.

You can also invest time in monitoring. If your mean time to fix is good, it balances out the time you put in testing... though this method won't save you time probably.

The key thing is focusing on keeping testing simple. I have experienced times where I have wasted more time writing tests than the actual implementation code. That taught me that my code was really complex and forced me to break it down in smaller modular components that were easier to test.

2 red flags I have learned to identify are: - The context to run the module is to complex (DOM emulation, protocol dependency) Leave that to End-2-End testing - Too much time invested on the test framework (Karma, Jasmine, Mocha, Jest) .Keep it simple

I recently wrote an article about this topic :

medium.com/@MarcFly1103/buckle-up-with-tape-1bd5e…

Also you could read:

medium.com/javascript-scene/what-every-unit-test-…

Thread

What to do when you can't write unit tests, but you want to ship a reliable product?

Responses(3)

Search Hashnode

What to do when you can't write unit tests, but you want to ship a reliable product?

Responses(3)